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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]