Classloading issue involving JAXBContext and JAXBContextFactory with webProfile-10.0 #28414
Comments
yogregg
added
the
release bug
|
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 The 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. |
|
Thanks for the quick response @neuwerk . I didn't want to clutter the problem report with them, but if the console logs with the behavior and classloader traces for the other scenario variations I mentioned would be helpful, I have them and could attach them. |
|
@yogregg if you haven't seen, I just wanted to let you know I was able to merge a fix (including tests that reproduced the failure). It should be included in the next release. I am going to close the issue for now, in the mean time you could also run against one of our nightly builds to verify the fix. If issue still persists let us know. |
|
@neuwerk thank you very much for the quick fix on this. I've verified it in a nightly build. |
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.logAdditional context
liberty_problem_202405_with_jaxb_api_and_webprofile_feature_console.log
liberty_problem_202405_with_jaxb_api_and_webprofile_feature_messages.log
The text was updated successfully, but these errors were encountered: