Hi,
I'm a developer on the Jetty HTTP server and servlet container and we've got a question about the best way we should be supporting CDI going forward, specifically now that transactions API has a hard JPMS dependency on CDI API.
Previous Jetty as a container has never provided CDI. Instead we have a variety of implementation specific and
standard based mechanisms to detect a CDI implementation within a webapp and to take the actions necessary to wire that up to our decorated object factory abstraction. CDI implementations also have some Jetty specific integrations that are fragile and often many major releases behind.
Thus the container has never provided the CDI API nor an implementation and instead we just work with the API/impl bundled in a webapplication.
However, with EE10, there is now a hard JPMS dependency from the jakarta transaction API to CDI API. As a container, in some configurations we use the transaction API as part of providing a data service to a webapplication, thus the jetty container provides the transaction API. But now JPMS insists that we also have the CDI API on the container classpath, which we are now doing in our Jetty-12 release.
But now we are in a bit of a dilemma. By default we hide the CDI API from a deployed webapplication, because we don't provide an implementation. This does allow webapps to continue to use their own bundled CDI API and implementation, but there are issues. Some mechanisms (e.g. MethodHandles) are able to see through the hiding of the container CDI API and then produce errors about two different versions (not sure why it bypasses the webapp classloader looking for other versions of the class only to then complain about it??). I also assume that if a container provided transaction was ever to meet up with some web app provided CDI implementation, that some expected behaviours might not work because the transaction classes are annotated with a different instance of the CDI API jar.
We did try exposing the container CDI API jar to the webapplication, but because the service loader is used by the CDI API to locate an implementation, the container CDI API does not see any implementation in the webapp (even if the thread context classloader is set to the webapp classloader).
So if we are to expose the CDI API, then the jetty container would also have to provide an implementation of CDI. We are totally fine with doing this, but we are wondering if that is going to be against the intention of CDI users? Is it the intention of CDI that an application should be able to bundle a specific version of the CDI API and a specific implementation of CDI in their web app and have that respected? Or is it OK for a container like jetty to ignore any webapp provided CDI and to instead provide the CDI API and an implementation to the webapp, that may be a different version and implementation from what they bundled?
Or do we need to support both? i.e. will some want CDI provided by the container and others want it to be provided by the webapp?
regards
-- 