commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Kitching (JIRA)" <>
Subject [jira] Commented: (LOGGING-25) [logging] call to getClassLoader() in LogFactoryImpl not checked for null
Date Sat, 16 Dec 2006 21:39:23 GMT
    [ ] 
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) {

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.



> [logging] call to getClassLoader() in LogFactoryImpl not checked for null
> -------------------------------------------------------------------------
>                 Key: LOGGING-25
>                 URL:
>             Project: Commons Logging
>          Issue Type: Bug
>    Affects Versions: 1.0.4
>         Environment: Operating System: other
> Platform: Other
>            Reporter: Luke Sleeman
> In line 374 of 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:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message