DO NOT REPLY [Bug 31740] New: - LogFactoryImpl bug? in class loading order...

[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=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: commons-dev@jakarta.apache.org
        ReportedBy: ervandew@yahoo.com


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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org