commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 31740] - LogFactoryImpl bug? in class loading order...
Date Sat, 16 Oct 2004 01:49:18 GMT
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...

craig.mcclanahan@sun.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From craig.mcclanahan@sun.com  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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message