This seems to imply that this is now a Servlet spec & Servlet TCK concern.
Which it has historically not been.
Eclipse Jetty works with Weld and OpenWebBeans.
Eclipse Jetty should be capable of working with about any CDI implementation, but that's not important for this.
The proposed requirements you are putting on the "Servlet Container" are not something Eclipse Jetty does.
I proposed to explicitly mention Jetty as a product that is 100% excluded from this requirement (next to a general text, that would also exclude standalone Tomcat, Undertow and Piranha among others).
Yet Eclipse Jetty works with CDI just fine without them.
Of course, Jetty always works. There is no problem with Jetty, and none of this should concern Jetty in any way.
Why? It is because the CDI implementation does this, not the Servlet Container.
That's not how it works, and I'm not sure how much more I can explain that it's not how it works, other than "trust me, I know what I'm saying", but I will try once again:
It's absolutely 100% NOT something for CDI implementations to do, which is also why it's being removed from the CDI specification text. It's a historical left over.
It IS about other specifications (and/or their integration code) to use CDI to provide beans of the given type.
For instance, Jakarta Faces makes a bean of type FacesContext available. Jakarta Security makes a bean of type SecurityContext available, etc etc. It's absolutely not the job of a CDI implementation (such as Weld) to provide those Jakarta Faces or Jakarta Security beans. Jakarta Faces and Jakarta Security can know about CDI, but CDI should not know about Jakarta Faces and Jakarta Security.
These stated requirements seem to be for CDI Implementations.
Once again, in the most strongest of wording; it is absolutely NOT for CDI implementations. Alternatively it can be in the Jakarta EE platform specification (as mentioned), but it is not something for CDI implementations. Even thinking that it may be something for CDI implementations is already a very big sign of misunderstanding what the ask is about.
Also only the CDI TCK has tests to check for these requirements.
But these were wrong, and are going to be removed. The CDI TCK also does not check all the Faces (JSF), Security, Transaction, WebSocket, Concurrency, etc etc beans. The fact that it did indeed check Servlet beans before was, as mentioned, a historical mistake which is now being corrected.
Kind regards,
Arjan Tijms
- Joakim (has no servlet spec role, just a community member)
Hi,
A Jakarta EE compliant server is required to make HttpServletRequest and a few other types injectable.
There was a requirement for that in the CDI spec, but that will be moved to "somewhere" else. The designated location for it is the specs that own the types, and otherwise it's the platform specification document.
The section in the CDI spec dealing with this now is:
The specific text for the Servlet types is:
"A servlet container must provide the following built-in beans, all of which have qualifier @Default:
a bean with bean type jakarta.servlet.http.HttpServletRequest, allowing injection of a reference to the HttpServletRequest
a bean with bean type jakarta.servlet.http.HttpSession, allowing injection of a reference to the HttpSession,
a bean with bean type jakarta.servlet.ServletContext, allowing injection of a reference to the ServletContext,
These beans are passivation capable dependencies, as defined in Passivation capable dependencies."
I'd like to propose moving this text to a section in the Servlet specification document, making it clear that it's only required in a Jakarta EE compliant profile (Web and Full), and specifically that Jetty (for example) does not need to do anything here.
Thoughts?
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
