neuwerk
commented
2 weeks ago Thanks for opening the issue, @yogregg, especially for providing such a deep background info. Its really really helpful.
That being said, we had a similar issue opened against our jaxb-2.2 feature, and ironically enough, I thought that the only EE platform that wouldn't have this issue is EE10. Looks like I thought wrong.
The cdi-4.0 feature has an dependency on the the XML Binding 4.0 specification APIs, and the cdi-4.0 feature is being pulled in automatically when you specify the webprofile-10.0 feature in your server.xml. This is why you were able to get it working when you specified only the features you needed from the webprofile-10.0, because you didn't need cdi-4.0. In EE 10, we stopped our internal XML Binding features (used by other features like 'cdi-4.0') from exposing its APIs to the application classpath. What I can't explain is why, now that we've stopped exposing them to the application classloader, you are even seeing this failure.
That being said, I would stick with using only the features you need for now as a temporary work around, and I will see what I can do to get a fix in for this.
yogregg
Describe the bug
I am having classloading problems with webProfile-10.0 and JAXB classes. My web application has jakarta.xml.bind-api 4.0.0 and jaxb-runtime 4.0.1 jars in its WEB-INF/lib. At startup, it attempts to create a JAXBContext using jakarta.xml.bind.JAXBContext.newInstance, but startup fails with an exception from there.
Here is the full stack trace from messages.log:
I turned on -verbose:class to see where classes are being loaded from, and here are the lines involving JAXBContextFactory (I've attached the full console.log and messages.log as liberty_problem_202405_with_jaxb_api_and_webprofile_feature_console.log and liberty_problem_202405_with_jaxb_api_and_webprofile_feature_messages.log):
The first two lines are both loading the jaxb-api interface for JAXBContextFactory, but strangely from two different locations: first from the jar included in my WEB-INF/lib, and then from one of Liberty's own directories. Then it loads the implementation class from an internal Liberty location, instead of from the jaxb-runtime jar that is in my WEB-INF/lib directory, and which also contains this implementation class. I think the fact that the interface is loaded from WEB-INF/lib but the implementation from an internal jar is confusing it into thinking that the implementation doesn't implement the interface, even though the JAXBContextFactory interfaces from the two locations appear to actually be identical.
I would not have expected any Liberty interfaces or implementations to get loaded for this when using webProfile-10.0, because the Jakarta EE 10 XML Binding specification is not part of the Jakarta EE 10 Web Profile spec. I would have expected it to solely load classes from the jars where they are available in my WEB-INF/lib.
I tried a few variations, and it got stranger. First, I tried removing the jakarta.xml.bind-api jar from my WEB-INF/lib, in hopes that it would then only load the interface once, from Liberty's own files. But that's not what happened. This time, it didn't ever load the api interfaces from anywhere at all, not even from Liberty's files as it did in the first situation. Instead, I got this different exception, and the classloader trace never shows it loading any JAXBContext* class:
So. in one case Liberty loaded the interface class from two places, and in the other case it didn't load it from anywhere at all.
Next, I changed the featureManager section to specify jakartaee-10.0 instead of webProfile-10.0. In this variation, the web application launched correctly, and a classloader trace showed it was loading both the interface and implementation jars from Liberty's files and it never loaded anything from either the jakarta.xml.jaxb-api or jaxb-runtime jars in my WEB-INF/lib.
Finally, I changed featureManager to just specify the minimal set of features that my web applicaiton actually needs: servlet-6.0, pages-3.1, ad websocket-2.1. The application also launched correctly in this configuration, but this time the classloader trace showed it loading all of the JAXBContext* classes from my WEB-INF/lib, and none of them from Liberty.
Steps to Reproduce
Build the attached small war file project using "mvn clean install" and Java 11 or later, then deploy it to a Liberty version in the range I mention in this problem report using the server.xml contents that appear later in this report (the important part is to have only the webProfile-10.0 feature enabled). The web application will not start correctly and you'll see the exceptions I described in messages.log and console.log, and if you enable classloader tracing by putting -verbose:class in jvm.options, you'll see classes being loaded from the multiple locations that I described above.
liberty_problem_202405.zip
Expected behavior
I expected the web application to start up without an exception, ideally by loading all of the classes involved from the jaxb-api and jaxb-runtime jars in my WEB-INF/lib, since XML Binding is not supposed to be included in Jakarta EE 10 Web Profile. But even if it did for some reason load classes from its own files (which are at the same spec level as in my war), I would have expected it to load without error.
Diagnostic information:
$WLP_OUTPUT_DIR/messages.log: attached as liberty_problem_202405_with_jaxb_api_and_webprofile_feature_messages.logserver.xml configuration:
Additional context
liberty_problem_202405_with_jaxb_api_and_webprofile_feature_console.log liberty_problem_202405_with_jaxb_api_and_webprofile_feature_messages.log