Re: [servlet-dev] What do we exactly dislike in Servlet?

[Joakim Erdfelt <joakim.erdfelt@xxxxxxxxx>]

I think it would make more sense to have an http-core spec.

The basics of serving http as an api.

This means:

• no sessions
• no authentication
• no streaming apis
• always async (if you want blocking calls, do it yourself.  none of this bolted on broken async that servlet has)
• no filters (this is just wrappers of the request or the response, and can be genericized)
• no listeners (pointless specialization, keep it generic)
• no url-pattern mappings (there's countless ways to map a request to an internal feature, let the users control how they want it)
• request is an interface (not an abstract class)
• response is an interface (not an abstract class)
• no complex war or ear magic
• no classloader isolation concerns
• no auto discovery of components
• no external configuration (xml, json, etc)
• entirely programmatic

This low level http api would be sufficient to build REST, Servlet, or whatever (grpc?) on top of.

The responsibilities of the http-api impls would be to handle the connections, the exchanges, the http/2+ streams, etc.

Transport concerns, compression, etc.

A user of the http-api would be able to control how the requests are handled, and provide the layers that they need.

I expect a healthy community to develop here to provide features (like single sign on, oauth, caching, sessions handling, etc) as standalone libraries that can be added into the handler tree of this http-api.

- Joakim

On Tue, Jul 12, 2022 at 2:57 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

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.

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.

Specifically, the Jakarta EE Core profile does not include Servlet support, which leads to various issues such as the one here: https://github.com/eclipse-ee4j/jakartaee-tck/issues/1096

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