Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [servlet-dev] Big ticket items for Servlet 6 / Jakarta EE 10?




I've very much against picking specific frameworks that we will support in servlets.

The problem is of course that Servlet is not so much an external random API, but is part of Jakarta EE. CDI here is also not just any random framework, but is the bean model and injection facility in Jakarta EE.

We definitely need to well support CDI, because it is important technology... not just because it is a co-component of EE.     It's status as a co-component means that it should be use-case #1 when motivating new features and evaluating proposals.

So yes let's definitely see what we can do to improve CDI integration, but let's do so in a way that doesn't have hard dependencies on CDI and can be used by other non EE frameworks that might come up with a different way of doing things than CDI... which might be better, worse or just different.

JSP is the counterexample to what I'm proposing because it is not lightly integrated into servlets.  It has special elements in the web.xml and special invocation modes that are not available to other frameworks (jsp-file).  When JSP was integrated, it should have been done so with generic mechanisms so that ultimately if/when JSP fades away the containers will not have legacy JSP support left over.  Moreover, if it had been done better that the specific use-case of jsp-file (defining a virtual servlet as an instantiation of a framework component) could have been generally available, so perhaps CDI could be used instead to provide instances of named servlets instead and we wouldn't now be needing to invent yet another integration mechanism!

As for where the actual integration impls live, that's a good question.    Let's say we add a standard decoration mechanism, so that a standard CdiSpiDecorator could be written, then should it live in Servlet or CDI?   Probably neither as you can see in Jetty's version we use MethodHandles to avoid hard dependencies on CDI.    Another project that could have hard dependencies on both Servlet and CDI would simplify this class.... However we can't do that yet because while CDI has a standard SPI, servlet doesn't have a standard decorator.   Ditto for Scoping (assuming that's what all the Contextual stuff in the SPI is about.... but I haven't bought your book yet so I'm just guessing:)

cheers



 
--

Back to the top