Good idea to start this discussion... might be hard process all the input, but worth the effort.
One of the pitched themes for Jakarta EE 10 is alignment, and for this theme I'd like to make a few proposals:
1. In cooperation with Jakarta REST (previously JAX-RS), see if we can define a subset of Servlet on which Jakarta REST can conveniently depend. At the moment most Jakarta REST implementations are based on Servlet anyway, but officially there's no such dependency.
Defining a simple subset of the servlet API that can be used for frameworks such as JAX-RS is a good idea as there are a lot of heavy weight features that are not necessary for many integrations. Of course the problem here is that any discussion of what is in/out of a profile (for that is what we are talking about) is always fraught. There is no one size fits all, but perhaps there can be a one size fits many. For my part, a minimal profile for Servlets would definitely exclude:
- Webapp layout - WEB-INF/web.xml, fragments etc.
- default servlet and static resources... at least by default
- JSPs
- A context classloader.
- Discovered Annotation and SCIs and anything requiring a full class scan.
- Cross context dispatch
- Distributed sessions
- resource / JNDI integration
- upgrade support
- Support for == identity of wrappers passed during dispatch.
Debatable features to include are :
- introspect annotations
- security support or at least a simplification of the security model
- include/forward dispatching.
Perhaps rather than just trying to define a single minimal profile, we could group features into named groups: webapp, JSP, Sessions, Security, CrossContext, Discovery, JNDI, Upgrade, etc. We could then allow a container implementation to declare which subset of these features are supported.... hmmm maybe that's a bad idea. But I'd love to be able to turn off support for some features whilst keeping others above a minimal layer.
2. For in a Jakarta EE environment, and as a separate related new spec, define a CDI version of Servlet, for instance with the proposed package jakarta.servlet.cdi. This would define what a Servlet would look like as a pure CDI bean, and in addition would finally allow us to transfer the HttpServletRequest producer that's now in core CDI itself.
I'm not keen on anything really specific for CDI. However, I definitely would like to see a standard way to open up the lifecycle of objects created by the container so external factories and/or decorators could be used by CDI, Spring and others
So if you frame this as to how to structure Servlets to be able to be assembled and injected by an arbitrary framework, then yes! I think this would work well with your point 1. Also ultimately the whole WEB-INF webapp thing could become just one implementation of a framework that assembles/injects servlets.
Alternatively this can also be proposed as a completely independent spec, not using the jakarta.servlet package, and just building on Servlet (like, e.g. Jakarta Faces does).
As much as I really hate many aspects of servlets... and recognise that good stuff can be done if we ditch many silly features, I think that the things you have proposed are achievable for servlet 6.0 without throwing away our heritage.
Anything else that's big? Any of the existing issues we'd like to prioritize for Servlet 6?
Several ideas here:
- With our split blocking/async IO system, it is very difficult to write code that intercepts arbitrary IO. Some standardized interception mechanism (perhaps based on reactive streams / Flows) would be good.
- Modernise a lot of the APIs to support modern JVM features
cheers
