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=31740>. 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=31740 LogFactoryImpl bug? in class loading order... [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From [EMAIL PROTECTED] 2004-10-16 01:49 ------- You'd be better off having a conversation on the Commons User mailing list on issues like this, reserving the issue tracking system for reporting bugs or making enhancement requests. That being said, the design decision on class loading order was very much a deliberate one. Consider the very common scenario of a servlet container that makes commons-logging available to all applications (such as by putting it in common/lib or shared/lib in Tomcat). Now, applications can use commons-logging without having to carry it around inside WEB-INF/lib. Now consider an app that wants to provide its own Log implementation (say, to prefix the current app's context path onto the log name before delegating to the standard implementation). The Log implementation itself would be included in the webapp, and the current class loading order (check the context class loader first) will find it. Your proposed change, however, would cause the custom Log implementation to NOT be found, because the search would start in the shared repository ... and you can only go UP a class loader hierarchy, not down. That's not acceptable. I've successfully used commons-logging inside things managed by Ant (such as JUnit based unit tests), but only with fork="true". It sounds like you should experiment with actually setting the context class loader to the one you want: Thread.currentThread().setContextClassLoader(...) and/or work with the Ant folks to understand how they set up their class loading architecture. But don't forget that everything in $ANT_HOME/lib is in the class loader hierarchy somewhere, in addition to things in the actual classpath. Also, JAR files can declare their own internal classpaths within the META-INF/MANIFEST.MF file, so you'll need to double check those as well for possible additional occurrences of commons-logging.jar. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
