[
http://issues.apache.org/jira/browse/LOGGING-25?page=comments#action_12459088 ]
Simon Kitching commented on LOGGING-25:
---------------------------------------
Applying this patch would cause some undesirable side-effects. For example,
method logClassLoaderEnvironment uses this method to print diagnostic info.
With this patch, we would report that a certain class was loaded from the
system classloader when it is really loaded from the bootclassloader.
I think it's better to fix the place(s) where we try to dereference this loader
without checking for null. Presumably you get an exception with a stack trace
when this occurs. Can you please run the standard JCL 1.1.1 release with the
following code and post the resulting exception? (please also include the
output of "java -version")
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class Tester {
public static Log log = LogFactory.getLog("foo");
public static void main(String[] args) {
log.error("testing");
}
}
java -Xbootclasspath/a:commons-logging-1.1.1.jar Tester
BTW, running the 1.1.1 release on Linux/java1.5 using
-Xbootclasspath/a:commons-logging-1.1.1.jar works fine. I'm pretty sure the
Apple JVM is just the Sun source code licensed by Apple and tweaked, so don't
know what could be causing a difference on Apple.
Thanks,
Simon
> [logging] call to getClassLoader() in LogFactoryImpl not checked for null
> -------------------------------------------------------------------------
>
> Key: LOGGING-25
> URL: http://issues.apache.org/jira/browse/LOGGING-25
> Project: Commons Logging
> Issue Type: Bug
> Affects Versions: 1.0.4
> Environment: Operating System: other
> Platform: Other
> Reporter: Luke Sleeman
>
> In line 374 of LogFactoryImpl.java getClassLoader() is called:
> logInterface = this.getClass().getClassLoader().loadClass(LOG_INTERFACE);
> However, the docs for getClassLoader() state that some implementations may use
> null to return the system classloader. This occurs under CrEme a JVM for the
> PocketPC platform which some of our products run under, causing a null pointer
> exception. Perhaps it would be better to change line 374 to read:
> logClass = loadClass(LOG_INTERFACE);
> which seems to solve the problems I have been having. At any rate calls to
> getClassLoader() should be checked to ensure that they haven't returned null.
> In addition the error that I got:
> org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException:
> java.lang.NullPointerException (Caused by java.lang.NullPointerException)
> (Caused by org.apache.commons.logging.LogConfigurationException:
> java.lang.NullPointerException (Caused by java.lang.NullPointerException))
> Certianly wasnt very helpfull for figuring out what is going on.
> - Luke
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
