Katja Zip created TOMEE-4242:
--------------------------------
Summary: Changed Default ClassLoader Behaviour
Key: TOMEE-4242
URL: https://issues.apache.org/jira/browse/TOMEE-4242
Project: TomEE
Issue Type: Bug
Affects Versions: 9.1.0
Reporter: Katja Zip
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:
{code:xml}
<Context>
<Loader delegate="false" />
</Context>
{code}
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?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
