While I certainly appreciate the
idea of aligning more Jakarta EE specifications
to CDI, who would really be the target audience
for a CDI based Servlet component model?
Wouldn't this audience in practice have a lot of
overlap with JAX-RS users? If so, is this an
effort worth undertaking? Maybe this is
something best pursued as an experimental
framework to see what the uptake would be
instead of work done in Jakarta?
I'm certainly willing to attempt it as an
experimental framework first. You're right that
there's a bit of an overlap with JAX-RS, though that
has always been the case to some degree.
The audience would essentially be people taking
advantage of all the traditional use cases for
Servlet; handling requests which are not essentially
restful in nature, and serving data accordingly. The
added value would the extra flexibility to apply
interceptors and scopes. Meaning that one can
install e.g. an HTTPAuthenticationMechanism, and
apply the more advanced security interceptor that
we're planning for Jakarta Security 3.
It's for that reason I proposed not adding any
fancy features. It are Servlets, but re-imagined as
beans.
Another, perhaps even more important reason for
this is to have a place to put the CDI based
producers (Bean<T>s really), which are now in
CDI core, to inject instances like the current
HttpServletRequest. Those are in need of some
overhaul (e.g, it's not at all defined which
*current* HTTPServletRequest is injected, think
original, vs wrapped, vs one after an include or
forward etc). The CDI spec has indicated those
things never belonged in CDI. CDI is to be used as a
foundation for other specs, not as a Facade for
Servlet and others.
Now we attempted to move these things to Servlet,
but that failed. Jetty is not specifically
interested in CDI (reiterated here above), and
that's what it is. It's their right to have that
opinion. We discussed it before, had different
opinions, but eventually resolved the discussion.
So instead of repeating all those discussions,
this new (small) CDI sub-spec / related standalone
spec could conveniently contain all the CDI
producers for Servlet types, and perhaps (if there's
interest) CDI versions of Servlet events.
Personally I think it is important
to try to align JAX-RS and Servlet if it is not
too late to do so.
JAX-RS seems unfortunately not interested in
re-basing on full Servlet, even though in practice
nearly all JAX-RS implementations are Servlet based.
The core HTTP library discussed here should be able
to stand a chance though, and that would be a good
step.
A related area to perhaps think
about is making Servlet more Reactive. Although
even in this space I am not sure what the
practical uptake has been, if there has been
sufficient maturity and what the impact of
Project Loom will be.
What is slam dunk for me is
working on the existing backlog of more minor
enhancements including keeping track of HTTP/3.
Yes, indeed.