Inline ...
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.
OK (but worried)
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).
That is what a "Servlet Container" has historically been.
The "Jakarta Web Profile" is where the CDI requirement that sits on top of "Servlet Container" has historically been situated.
What happened to the Jakarta Web Profile that used to do this?
The proposed text should mention that it is not a "Servlet Container" requirement, but a "Jakarta Web Profile" requirement.
No need to point out specific "Servlet Container" implementations.
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.
Where would the TCK tests for these new requirements be?
Seems like putting them into the Servlet TCK would mean that most "Servlet Container" implementations wouldn't be able to pass the TCK then.
And if weld/openwebbeans (and similar) remove this feature / support, then there is no means for a "Servlet Container" to provide that for the Servlet TCK.
Feels smarmy to need to include a different spec implementation just to pass a TCK. After all, we don't test for JFaces or JSP or WebSocket when testing a "Servlet Container" via the Servlet TCK today.
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.
Removed, interesting, who is going to create (and run) the replacements of these removed tests then? It would be difficult for a spec group that doesn't need / use CDI to do it.
It sounds like only implementations of the various jakarta profiles would need it and be testing it.
- Joakim (again, just a community member, I have no role in the servlet spec group)
