[
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.
