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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
