DO NOT REPLY [Bug 27374] - ClassLoader clashes

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27374>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27374

ClassLoader clashes

craig.mcclanahan@sun.com changed:

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



------- Additional Comments From craig.mcclanahan@sun.com  2004-03-06 22:00 -------
Unfortunately, using Class.forName() to load the Log class in question would
break all uses of commons-logging in scenarios like Tomcat, when you want to use
c-l loaded from common/lib and a custom Log implementation class loaded from
within your web application.

The underying issue is that having org.apache.commons.logging.Log visible in
more than one class loader in your class loader hierarchy is always going to
fail.  This is the reason, for example, that the JUnit tests in the build.xml
file for commons-logging itself use fork="true", so that the class loader used
by Ant is not visible.  You should investigate whether IntelliJ has some sort of
similar configuration switch, to run the unit tests in a separate JVM.

Note that the error message produced when multiple cases of o.a.c.l.Log are
detected has been improved to state that this is the real problem, rather than
implying that the selected Log implementation class does not actually implement
this interface.  See:

  http://issues.apache.org/bugzilla/show_bug.cgi?id=25156

for more information.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org