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?
Well, as a counter question / remark. Look at what a "Transaction Manager" has historically been. How is it possible that the Jakarta Transactions specification now (since Java EE 7) defines a CDI interceptor (@Transactional) and a CDI scope (@TransactionScoped) for usage within an Jakarta EE environment?
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.
They all would be able to pass, by definition.
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.
Which means, unfortunately, that the ask is really not understood still. As this is so fundamentally different.
Jakarta Faces uses Servlet, so Jakarta Faces knows about Servlet. The other way around, Servlet should absolutely not know about Faces. The fact that you mention this does mean you understand why Servlet should not test for Faces.
In exactly the same way, CDI should not test for Servlet. CDI should not test for artefacts it doesn't own or manage.
But in a Jakarta EE environment, specs should integrate with CDI. So for a Servlet Container this means it should make the artefacts it owns available via CDI (so all other specs in that environment can consume them). In that environment, and only in that environment, a Servlet Container therefore uses CDI.
But Jetty itself is not a Jakarta EE environment, so Jetty is *by definition* excluded from doing anything here.
That aside, to support the requirement (even if Jetty doesn't need to do it), is much simpler than I guess you think it is.
It's something like
public class CdiExtension implements Extension {
public void afterBean(final @Observes AfterBeanDiscovery afterBeanDiscovery) {
afterBeanDiscovery.addBean([Get current request from Jetty specific location]);
}
}
There is nothing about Jetty having to implement the CDI specification, or Jetty having to support Weld and OpenWebBeans, or including all or any of that. That is not the case. It's only about that small extension, that, again, Jetty would not even be obliged to deliver.
It sounds like only implementations of the various jakarta profiles would need it and be testing it.
To make things consistent, you would suggest that Faces, Concurrency, Security,Transactions etc etc all remove their text about making Beans available within a Jakarta EE environment, and move that all to the Jakarta profiles? At the moment, Servlet is basically the only spec that doesn't do it like all the others.
I know that the fact that Servlet is part of Jakarta EE is... troublesome. Maybe you want Servlet to not be a part of Jakarta EE, but the perhaps somewhat unfortunate fact is that it is. So naturally there is some tension here. On the one side we have Jetty, which lives completely outside of Jakarta EE and doesn't care for Jakarta EE (no criticism, that's just how things evolved, for good business reasons). On the other side we have the Jakarta Coordinators and maintainers of Jakarta EE, who see Servlet as a part of the platform, and are trying to make the platform consistent.
Kind regards,
Arjan Tijms
- Joakim (again, just a community member, I have no role in the servlet spec group)
