DO NOT REPLY [Bug 28291] - [logging] ContextClassLoader may load Log impl from wrong context in JDK 1.4

[bu...@apache.org]

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=28291>.
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=28291





------- Additional Comments From rsitze@apache.org  2005-01-27 21:34 -------
The opening statement is not necessarily true:

"...  If this ClassLoader [Thread.currentThread()] is different from the
ClassLoader which loaded org.apache.commons.logging.Log, the implementing class
cannot be cast to Log."

Specifically, with the [default or expected] ClassLoader rule of deferring to
the parent ClassLoader first, the implementing class will extend the Log class
defined by the parent, and hence it can be cast.

The discovery mechanism for commons-logging currently overlooks/assumes two points:
1. That the thread-context class loader is a child who's parent hierarchy
includes the commons-logging.jar.
2. That the ClassLoaders in the current hierarchy exhibit the default
parent-first behavior.

I'm guessing it is this later scenario that some combination of JUnit/Cactus is
doing.

Would you help confirm this analysis of your problem?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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