-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
None
Since the cdi api spec changed to using the ServiceLoader to find the CDI implementation, it leads to some classloader issues on servlet containers such as Jetty with the newer versions of some of other standard apis.
In particular, the tansaction api has started to depend on the cdi api, thus a servlet container such as Jetty now needs to also have the cdi api on the server's classpath. This means that by default, if the weld impl is not also on the server classpath, the ServiceLoader cannot find the cdi impl .
Is this change intentional? We have done some work-arounds in Jetty to hide the cdi-api on the server's classpath, but it still feels wrong to have the same jar on both the server classpath and also the webapp classpath. What's the best practice here? Should Weld consumers now be putting Weld onto the server classpath, or do you recommend to still keep it on the webapp classpath?