commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Kitching (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
Date Fri, 03 Aug 2007 08:22:52 GMT

    [ https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517484
] 

Simon Kitching commented on LOGGING-114:
----------------------------------------

Rather than use smtp appender, presumably the log4j config file could also just reference
an appender that doesn't exist, eg "example.no.such.appender".

However why should log4j be called directly? I thought the problem is that when JCL is called
directly and log4j is not yet initialised, this causes log4j to auto-initialise which then
fails.
JCL then *silently* selects a different logging system where it should at least write a message
to the diagnostics.

Presumably this test would need to catch stderr (ie the diagnostics output) and search that
output text for a message stating that log4j was not selected because it failed to initialise.

The test will need to be careful to restore stderr to its original destination in all situations;
it would be awkward if the unit test left stderr redirected ;-)

Another useful test might be to check what happens when the commons-logging.properties file
explicitly selects log4j and it fails. I don't actually know what we do in that case (will
check...)

> Silent Swallowing of NoClassDefFoundError
> -----------------------------------------
>
>                 Key: LOGGING-114
>                 URL: https://issues.apache.org/jira/browse/LOGGING-114
>             Project: Commons Logging
>          Issue Type: Bug
>    Affects Versions: 1.1.0
>         Environment: Various OSs, in combination with log4j 1.2.14.
>            Reporter: Malcolm Cleaton
>            Priority: Minor
>
> Hi. I'm using commons logging with log4j; my team ship a library which uses log4j, and
some of our clients use it with commons-logging.
> If commons-logging is in its default configuration, and log4j is present but fails to
load its configuration with an unhandled exception, the results are pretty nasty:
> - commons-logging silently swallows the exception and logs with something else. If diagnostics
are turned on, the message is:
>     Could not instantiate Log 'org.apache.commons.logging.impl.Log4JLogger' -- java.lang.reflect.InvocationTargetException:
null
> - future attempts to use log4j directly get a pretty unhelpful error:
>     java.lang.NoClassDefFoundError at org.apache.log4j.Logger.getLogger(Logger.java:117).
> I realise you're trying to deal with a very large number of cases in this code, but it
does seem like something better could be done here. If nothing else is possible, at least
recognising the InvocationTargetException and pulling out the target exception for the diagnostic
log would have helped with tracking this one down.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message