-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Having trouble setting up custom Weld on jetty12 #10150
Comments
Server level CDI has always been problematic. There was a time back in Jetty 9 where we attempted to get CDI working at the Server level properly, but it failed. As to how things are loaded with the Jetty CDI module, all lookups are done via the context's ClassLoader first. You can check the jetty server dump for details.
Look for the entries about Example:
I think the 3 lines ...
.. are impacting you. |
In short, if you want your webapp's CDI to be used, then don't enable the server level CDI modules. |
I got the dump
How do I disable the server level CDI module? As I have not enabled it in my knowledge? The Enabled Modules I mentioned before does not mention CDI anywhere.. |
I also tryed to get a dump with application deployed, but this one just overflows :P a bug? |
But yes If I kill the process before the overflow i see:
Maybe the default should not include jakarta.enterprise.* ? or maybe the jakarta.enterprise. is a undeclared depenecy of a module enabled for some reason.. |
Do you see something like the following?
Notes for others researching this, the simplest way to replicate the above stacktrace is ...
|
Yes, I started my investigation from there. and the jakarta.enterprise.inject.spi.CDI comes from the server and not my webapp. I have no idea why the server provides it, as I have not enabled servers CDI modules to my knowledge. |
We have a replication case, no server level CDI enabled. Oddly we have passing CDITests in our distribution tests. |
oh nice:)
|
@joakime I vaguely recall that one of the updated jakarta API jars has a hard JPMS dependency on the CDI API. I think we are providing it by default because of that. I wonder if we can do some config magic so that it is hidden from the webapps unless we explicitly enable that as a module? I'll investigate more soon |
So we now have @sbordet I know this is REALLY late in the day.... but could we have dependencies that are only put on the classpath if we are running in jpms mode? |
@andresluuk can you try running with an extra module enabled? Create the file
then enable that module and run again. That should hide the CDI jar and might help. |
Thank you, I tryed it out and I got my CDI application working with it. |
Just a side note. I think the classloader dumping (jetty.server.dumpAfterStart=true) endless loop deserves also a check:
The jakarta.faces-3.0.0 in the webapp is the default one from maven. |
@gregw wrote:
I'm not sure I understand the problem? If there is no hard dependency on the module-info, then we also should not have CDI as a hard dependency and all will work. If there is a jakarta jar that lists CDI as a non-static dependency, but that is not required, then it's a bug in the jakarta jar. |
I don't know if they don't use CDI or if it is just that we don't use any API that needs CDI. So I know is that we never needed the CDI dependency before, but now we do because of JPMS. I'll drive deeper the next few days. |
@sbordet The jakarta transaction api does use some classes from the jakarta cdi api, specifically:
So it looks like they are real dependencies even though they are not in the main API, they are annotations that CDI will look for. Thus we now have a hard dependency on a specific version of the CDI API which we are currently exposing to the webapp. Thus we need to need to hide these APIs from webapps, that might have different versions of CDI. |
What is the final result here on jetty 12.0.0 when it is released. Should I keep the special custom module, or it is no longer needed? |
For now the custom module will still be required. We need to gain more experience with his the change in Jakarta APIs to depend on CDI affects deployments. I.e. is there a bug (so we should hide it) out a feature (we should embrace it and maybe even provide a CDI implementation). So for now if you use any jetty plus features (annotations, JSP, jndi) then you will get a CDI API in your class loader. If the webapp wants to use CDI, then either it needs to be at the same version or do a custom module to hide the container provided version. |
Ok, I will continue with the special module then.
Just to clarify by "same version" you mean here use the CDI provided by the jetty, as the issue was that because of the API on the server path you can't provide any (including one matching the servers CDI apis) CDI versions by the webapp classpath. |
This issue has been automatically marked as stale because it has been a |
We need to have a look at the current state of this before releasing 12.1.0 |
weld 5.1.2.Final with Jetty 12.0.12 embedded ee10 works just fine. What do we need to check? |
@joakime we need to check if the use of the transaction API still has a hard dependency on CDI, so if we expose transactions to a webapp that is using its own CDI, do we have a clash of versions? Or have they removed the hard CDI dependency from transactions? |
@gregw it is there, but listed as Transactions v2.0.1 - https://github.com/jakartaee/transactions/blob/2.0.1/api/pom.xml#L316-L321 |
Latest jetty12 build with ee9 or ee10
JDK 17.
I can see that jetty12 has CDI modules and we probably could enable those to get jettys internal weld CDI working, but for the purpose for this question I would no enable those modules.
I have a standalone weld 4 war (but I had the same issue also with weld 5.1), that is working in jetty11. The war contains all the files and APIs needed for weld. Looking at code I can see that it uses ServiceLoader (from jakarta.enterprise.inject.spi.CDI) to find out it's provided CDI implementation.
I can see that the service interface is loaded from the application:
'jar:file:/C:/work/servers/jetty-home-11.0.12/webapps/exp-weld40-beanClassAdd/WEB-INF/lib/jakarta.enterprise.cdi-api-3.0.0.jar!/jakarta/enterprise/inject/spi/CDIProvider.class'. And now it finds the implementation from WEB-INF/lib/weld-servlet-core-4.0.3.Final.jar
Now when I deployed the same application on weld12ee9 (also the same on weld12ee10) I can see that the interface is found from:
file:/C:/work/servers/jetty-home-12.0.0-SNAPSHOT/lib/jakarta.enterprise.cdi-api-3.0.1.jar!/jakarta/enterprise/inject/spi/CDIProvider.class And later on the implementation from weld-servlet-core-4.0.3.Final.jar is not found. The jar WEB-INF/lib/jakarta.enterprise.cdi-api-3.0.0.jar also exists, but CDIProvider is found from the server and for some reason, it does not find the implementation provided by the application.
I digged a little deeper and found out that the classpath has changed:
jetty11:
jetty12
Jetty 11 did not have jakarta.enterprise.cdi-api-3.0.1.jar on server classpath. Is it there by design? I have not enabled any CDI modules in my knowledge:
Are there any suggestions in order to get the service loader working again?
Maybe I can turn the application into child-first classloading somehow in order to get it working?
Can I remove the jar from servers classpath somehow?
Or if the interface is in the servers classpath, it should still find the implementation in the application..
The text was updated successfully, but these errors were encountered: