DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=28291>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28291 ContextClassLoader may load Log impl from wrong context in JDK 1.4 Summary: ContextClassLoader may load Log impl from wrong context in JDK 1.4 Product: Commons Version: 1.0.3 Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Logging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
