[
https://issues.apache.org/jira/browse/TOMEE-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780380#comment-17780380
]
Katja Zip commented on TOMEE-4242:
----------------------------------
I am using slf4j-api-1.7.36 and Apache Tomcat (TomEE)/10.0.27 (9.1.0)
slf4j-api-1.7.36 is also the version which is part of /var/lib/tomee/lib
> 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
> Priority: Major
>
> 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)
