Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
9.1.0
-
None
-
None
-
None
Description
We are migrating a Web-Application from TomEE 8.0.14 to TomEE 9.1.0. On the new TomEE version we encounter problems in class loading. One of the symptoms is, that SLF4J no longer used the application specific binding to logback, but the TomEE configured JUL binding instead. This is caused by resolving the SLF4J LoggerFactory from the parent classloader. If we include a context.xml in our application's META-INF folder with the following content, the problem disappears:
<Context> <Loader delegate="false" /> </Context>
If the delegate property is set to true, we get the same behaviour as we experienced without the context.xml.
This is an unexpected change in the TomEE behaviour between the two versions. It indicates, that true is likely the default behaviour. This is opposite to the Tomcat documentation, which indicates false to be the default: https://tomcat.apache.org/tomcat-10.0-doc/class-loader-howto.html. Furthermore, the Java Servlet specification also states, that the application classes should bee loaded before the system classes.
Why was the default behaviour for the class loading changed? Are there other implications, that we need to be aware of, that our mitigation causes?