You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2002/10/19 19:44:02 UTC
DO NOT REPLY [Bug 9845] -
Default LogFactory Implementation fails for Log4J : ClassCastException
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=9845>.
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=9845
Default LogFactory Implementation fails for Log4J : ClassCastException
rsitze@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |LATER
Summary|Default LogFactory |Default LogFactory
|Implementation fails for |Implementation fails for
|Log4J |Log4J : ClassCastException
------- Additional Comments From rsitze@apache.org 2002-10-19 17:44 -------
This is a KNOWN problem with J2EE and (other) managed environments where there
are multiple instances of commons-logging.jar (and/or commons-logging-api.jar).
[I'm changing this to 'LATER' to move it out of the open problem category,
but also to leave it open for futher comment/suggestions/discussion]
The problem is that you have different parts of commons-logging being loaded
by different classloaders, and though they have the same NAME, they are not
the same class (diff classloader). So... class cast exception.
This is NOT easily fixed in commons-logging, though providing details on your
environments and any work-arounds you might be able to provide would be usefull.
Any JUnit Guru's out there? Can this be caused by using commons-logging at
various levels within the test suites?
<ras>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>