[ 
https://issues.apache.org/jira/browse/TOMEE-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780405#comment-17780405
 ] 

Jonathan Gallimore commented on TOMEE-4242:
-------------------------------------------

Ok, sounds like you have: slf4j-api-1.7.36.jar in the TomEE lib, and 
logback-classic-1.2.11.jar in the web app's WEB-INF/lib. I'll add a test for 
that.

I'd definitely expect your use-case to work if you also include 
slf4j-api-1.7.36.jar in your webapp as well as logback (sounds like you have 
already done that, and it works).

> 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)

Reply via email to