Hi,
The topic came up a couple of times that people/vendors dislike "things" in Servlet, and therefore need to exclude it from their products.
From the Quarkus point of view we base our HTTP stack on Vert.x rather than Servlet. Servlet is optional, and if you include it then things will run on top of it, but we don't really recommend it as for most users it is not necessary.
Basically our standard stack would look like:
Netty -> Vert.x -> RESTEasy Reactive
But if you include Servlet then you get:
Netty -> Vert.x -> Undertow -> RESTEasy Reactive
If you go the second approach you can use Servlet Filters, however you lose reactive support as every request needs to be moved to a blocking thread for Servlet. Even for blocking requests it is just faster to not include a Servlet layer if you don't actually need it.
Stuart
For years Servlet was the common way to respond to HTTP requests, but since Servlet is being disliked for some reason, we unfortunately don't have that common HTTP API anymore.
In general, I think not having a common HTTP API in Jakarta EE is extremely problematic. Issue 1096 above is only one example of that. It has been discussed in the Servlet spec team before to look at a Servlet-lite profile, but I think we need the input of the other teams to figure out what exactly they dislike so much. If we have a clear list of things that are disliked then those could be potentially excluded from such Servlet-lite profile.
One argument I heard is that Servlets are much, much slower than Jakarta REST. But I'm not quite sure why a Java class that implements jakarta.servlet.Servlet should be slower in any way than a Java class with the @Path annotation.
Any pointers would be much appreciated.
Kind regards,
Arjan Tijms
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
