Nicolas Duminil

It would have been interesting to separate the authorization service from the application controller, in a dedicated Maven module. As a matter of fact, in production ready application, mixing this two distinct responsibilities is an anti-pattern.

Also, all the operations required to configure the security realm are laborious. Why don't you provide a kcadm script which does that ? And to run it from Maven ?

Last but not least, I'd suggest that you use a docker-compose plugin for Maven such that to perform all the required operations by running `mvn install`.

Thanks for your comments.

This is really a great post demonstrating how to simplify cross cutting concerns representing more than 70% of the enterprise grade applications code. Thanks for sharing Martina.

I'll let you with your own contradictions and won't insist any more but, for me, what you're saying, doesn't make sense.

"I'm not against interfaces". Well, you seem to be since you're recommending to remove them, as far as they don't have several implementations. You prefer to refactor your code whenever a new concrete implementation of a service is provided, instead of having a default implementation ruled by an interface. But how a new implementation of a service might be provided, given that the service doesn't have an interface and, hence , it isn't even a service ?

As I said, this is really poor design because it lacks abstraction, it lacks the possibility to provide several concrete implementations of the same service and, finally, it lacks extensibility. And since you're recommending to use design patterns, I would be curious to understand how do you think to use the template one, without interfaces ? For memory, a template is an abstract definition of a service, potentially having several concrete implementations.

But just to make sure I correctly understand your point: how do you deal with functional interfaces ? Since you recommend not having single implementation interfaces, you're probably recommending even more not having interfaces without implementations at all. So, how would you write Lambda functions in this case ? Or you're recommending not using Lambda functions neither ?

"If a solitary implementation of an interface exists, then consider removal". This is a highly questionable point. You're neglecting the functional interfaces which don't have implementations at all and which instances are represented by Lambda functions.

Additionally, your point isn't correct as having only one implementation at a given moment doesn't mean that other new implementations can't be provided later and removing the interface would lead to a poor design. Think at SPI (Service Provider Interface) pattern which, often, has only a default implementation, allowing other providers to suply their. Think also at CDI alternatives which couldn't exist without initial single implementation interfaces.

Lacking or removing intrrfaces is a very bad practice.

One of the fundamental theorem in software design, forged by David Wheeler, says: "Any problem in computer science can be solved by an additional abstraction layer". And abstraction layers are contracts, i.e. interfaces.

Another well known OO principle says: "code against interfaces, not against implementations".

Suppressing interfaces, as shown in the post, and coding against classes, i.e. against implementations, might prevent all the callers from working as soon as the implementation changes.

Another OO rule recommends to never expose implementations and this is, among others, the role of interfaces.

Last but not least, don't forget functional interfaces which are interfaces that specify exactly one one abstract method.

Having unnecessary interfaces isn't good neither but this is not really the problem. The real problem is, more often than not, the lack of interfaces, which leads to a lack of the code abstraction and, consequently, to the infringement of the Liskov principle.

Many thanks for your comments.

Not sure what this comment is meant to. If you want to write your own article, then please do, be my guest, no need to do it as a comment to the mine. Given that you're not asking any question and you're not bringing any new point in the discussion, I don't know what kind of reaction do you expect from my part.

Since you don't seem to remember any more what exactly did you ask, please let me refresh your memory.
A quick glance at the exchanges above shows that you've asked "Aren't you comparing Spring Boot vs Quarkus and not Eclipse MP ?". This was your question.
And I'm answering that Eclipse MP is just a specification and, accordingly, when it comes to test it, one could only test a specific implementation of it, as testing Eclipse MP itself wouldn't be possible, since is just a specification. :-)
However, while testing a specific implementation, I'm testing standard Eclipse MP features that all the existent implementations support. I'm not testing any specific Quarkus feature which wouldn't exist in Eclipse MP. In this sense, I'm saying that I'm comparing Spring Boot with Eclipe MP.

Hoping that, this time, I managed to answer your question, such that we could get it to closed.

Why don't you write your own article to explain all that instead of tire me with these questions ?

"The only case where you could care about TFR is if you are using lambda". I take it that by "lambda" you mean here "serverless", as there is no reason to isolate the discussion to only AWS. And no, you're wrong, as this is not the only case when TFR is a significant metric. While it might not be a central concern in monolithic applications, for micro-services, in general, not only serverless based micro-services, TFR impacts the cost and the availability of the running applications.

Who cares about TFR ? Those who care abour content delivery and latency.

Since the example project doesn't use any Quarkus specific feature, only standard Eclipse MP ones, I'm comparing Spring Boot with Eclipse MP. And yes, Eclipse MP is a standard with multiple implementations, like Quarkus, Helidon, Wildfly, Payara, OpenLiberty and others, while Spring, in general, including Spring Boot, Spring Cloud, etc., is just a Java library which isn't aligned to any standard. Hence, it doesn't make sense to talk about implementations as far as Spring is concerned, because there is noting to implement. Spring provides whatever features and functions its owner thinks as being useful.

Hoping to have clarified the point. Thank you for your comments.

Thnaks for your comment.
1. This archetype doesn't aim at demonstrating neither JSP, nor Jakarta Faces with Facelets. It includes a pure HTML page that might be useful in order to test the effectiveness of the WAR deployment.

2. It is not necessary to use Linux shell, you only need to run 2 Maven commands and a Docker one. And since these commands might be too long to be typed in each time, it's preferable to include them in shell scripts. Why Linux scripts ? Because it happens that I'm a Linux user. What should Windows users do ? Given that the Maven and Docker commands are the same whatever the OS is, Windows users can just run the same Maven and Docker commands or slightly ammend the given scripts such that to be Windows compliant.