[LOGGING-34] [logging] ContextClassLoader may load Log impl from wrong context in JDK 1.4

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Cannot Reproduce
• Affects Version/s: 1.0.3

Environment

Operating System: other
Platform: All

• Bugzilla Id: 28291
• Assignee: Unassigned
• Reporter: Chris Eldredge
• Created: 09/Apr/04 01:58
• Updated: 02/Jan/08 07:48
• Resolved: 02/Jan/08 07:48

Description

The static method org.apache.commons.logging.LogFactory#getContextClassLoader
will return the ClassLoader for the currently executing thread
Thread.currentThread(). If this ClassLoader is different from the ClassLoader
which loaded org.apache.commons.logging.Log, the implementing class cannot be
cast to Log.

This results in Log.class.isAssignableFrom(logClass) returning false even
though logClass implements Log. In turn, this causes
org.apache.commons.logging.impl.LogFactoryImpl#getLogConstructor() to
incorrectly throw the exception "Class " + logClass + " does not implement Log"

The solution is to use the same ClassLoader that was used to load
org.apache.commons.logging.Log.

On line 463 of LogFactoryImpl.java, replace the line:
ClassLoader threadCL = getContextClassLoader();

with:
ClassLoader threadCL = Log.class.getClassLoader();

The only was I am aware of to reproduce this bug is to write a Jakarta Cactus
Test Suite and run the test using junit.swingui.TestRunner.main or
junit.awtui.TestRunner.main. Because the Thread has a different
ContextClassLoader, commons-logging will fail to instantiate the Log
implementation.