[
https://issues.apache.org/jira/browse/LOGGING-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873337#comment-17873337
]
Björn Kautler edited comment on LOGGING-192 at 8/13/24 10:06 PM:
-----------------------------------------------------------------
This simple Groovy snippet also reproduces the problem:
[MCVE|https://groovyconsole.dev/?g=groovy_4_0&codez=eNqlkE9Lw0AQxe_7KXJLFuxAG08BoaLoJSj45xRymG6maUKyEyZbtd_eSSxSBEHswu7ymJn3fsz6XnCgMSlMpGetapPEjvue_bjouK4bX2c_9RJSSGN7cTrDUgMO6HYEx7bpv2yz-V3g0GQrWKWwjK0prWn6gSVELb4hdKjNj5uWXDCmom0UnOuiq8jTe_T6lN90OI45Y0WSFLOALcsD9vR7KuSqSGILg3BQ44b9LffYeHBc0TPvxU0jDqdKCYGvRfCQaFxRZpkmWzuj_IfkuK5vImW5QxdYDufxmJedEFbg9iLkw5dKrDr4QB_hhE6Rpx0avWqK1Vz6O2NNQXUSx_YTnYm8QQ]
{code:groovy}
@Grapes([
@Grab('commons-logging:commons-logging:1.3.3'),
@Grab('org.apache.logging.log4j:log4j-api:2.23.1')
])
import java.lang.Object
def tccl = new
URLClassLoader([Class.forName('org.apache.logging.log4j.Logger').protectionDomain.codeSource.location].toArray(URL[]::new))
def ccl = new
URLClassLoader([Class.forName('org.apache.commons.logging.LogFactory').protectionDomain.codeSource.location].toArray(URL[]::new))
Thread.currentThread().contextClassLoader = tccl
ccl.loadClass('org.apache.commons.logging.LogFactory').getLog('')
{code}
was (Author: vampire):
This simple Groovy snippet also reproduces the problem:
[https://groovyconsole.dev/#PTrLLEx4GY]
{code:groovy}
@Grapes([
@Grab('commons-logging:commons-logging:1.3.3'),
@Grab('org.apache.logging.log4j:log4j-api:2.23.1')
])
import static org.apache.commons.logging.LogFactory.getLog
def tccl = new
URLClassLoader([Class.forName('org.apache.logging.log4j.Logger').protectionDomain.codeSource.location].toArray(URL[]::new))
def ccl = new
URLClassLoader([Class.forName('org.apache.commons.logging.LogFactory').protectionDomain.codeSource.location].toArray(URL[]::new))
Thread.currentThread().contextClassLoader = tccl
ccl.loadClass('org.apache.commons.logging.LogFactory').getLog('')
{code}
> NoClassDefFoundError: org/apache/logging/log4j/spi/LoggerAdapter when using
> custom classloader
> ----------------------------------------------------------------------------------------------
>
> Key: LOGGING-192
> URL: https://issues.apache.org/jira/browse/LOGGING-192
> Project: Commons Logging
> Issue Type: Bug
> Affects Versions: 1.3.0, 1.3.1, 1.3.2
> Environment: This behavior was observed while running Adopt Open JDK
> 11 and the latest version of Tomcat 9. The behavior can be reproduced
> outside of tomcat (see attached reproduction case).
> Reporter: Dave Dority
> Priority: Major
> Attachments: commons-logging-classloading-issue.zip
>
>
> If you have:
> * A web application running in Tomcat which contains commons-logging:1.2
> * That web application contains a custom classloader for loading a
> seperately distributed software component (whose dependencies will conflict
> with the dependencies of the web application).
> * The software component uses commons-logging:1.3.2
> When the web application attempts use software component, the code
> [here|https://github.com/apache/commons-logging/blob/rel/commons-logging-1.3.2/src/main/java/org/apache/commons/logging/LogFactory.java#L918-L938]
> looks for the presence of different logging implementation classes on the
> thread context classloader's (TCCL) classpath to select an optimal
> implementation. It seems like what is happening is that the LogFactory class
> looking for implementation class on the TCCL's classpath and the trying to
> load the selected factory from the web application's custom classloader (the
> loader for the instance of LogFactory that is running). This is the result:
> {code:java}
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/logging/log4j/spi/LoggerAdapter
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:315)
> at
> org.apache.commons.logging.LogFactory.createFactory(LogFactory.java:419)
> at
> org.apache.commons.logging.LogFactory.lambda$newFactory$3(LogFactory.java:1431)
> at java.base/java.security.AccessController.doPrivileged(Native
> Method)
> at
> org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:1431)
> at
> org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:928)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:987)
> at
> org.component.ClassLoadedComponent.<clinit>(ClassLoadedComponent.java:7)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at java.base/java.lang.Class.newInstance(Class.java:584){code}
> This occurs when the web application has commons-logging:1.2 and the software
> component has commons-logging:1.3.x. This does not occur when both are using
> version 1.2.
> Unfortunately, changing the web application's version of commons-logging is
> outside is not something I can influence.
> An isolated reproduction case is attached. It requires Java 11. To run it:
> * Unzip it to a directory.
> * Run
> {code:java}
> ./gradlew reproduceIssue{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
