commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 27374] New: - ClassLoader clashes
Date Tue, 02 Mar 2004 17:40:22 GMT
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=27374>.
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=27374

ClassLoader clashes

           Summary: ClassLoader clashes
           Product: Commons
           Version: 1.0.3
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Logging
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: tilo.christ@siemens.com


LogFactoryImpl.getLogConstructor() uses two different means to obtain classes. 
It uses Log.class to obtain the class for the Log interface and the 
LogFactory.loadClass(className) method to load the actual implementation. 
This can result in failure when isAssignable is invoked to make sure they can 
be assigned to each other. This situation happens in my case when I try to use 
commons logging from the JUnit testrunner in the IntelliJ IDE. I fixed the 
problem by using Class.forName() to load the implementation of the logger.
It doesn't work the other way around (using loadClass() to load the Log 
interface) because then the entire framework fails. The reason is that Log as 
being loaded by loadClass is then no longer castable to Log as used by your 
APIs.

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


Mime
View raw message