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=31740>. 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=31740 LogFactoryImpl bug? in class loading order... Summary: LogFactoryImpl bug? in class loading order... Product: Commons Version: 1.0.4 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Logging AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] in loadClass(String) the current implementation trys to load the supplied class name by first using the context classloader, then trying a simple Class.forName(). Is there a particular reason why it's not the other way around? I ask because i've gotten very weird behavior using ant and ejbdoclet (xdoclet). When building several modules at once and running xdoclet several times, at some point (after several ejbdoclet calls have succeeded), ejbdoclet suddenly fails with ... "Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed." There are no other jars in the classpath containing this class. I narrowed it down to the fact that the failure occurs when the context classloader is the one that finds the class. If i swap the order and have Class.forName execute first then everything works fine. I think the root of this issue may be a bug in ant, since i can run the module that fails independently and it builds fine. It's only when run after other modules in a single ant script that it fails. So, i'm hoping that there isn't a need to use the context classloader first, but instead the Class.forName can be given precedence. Thoughts? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
