[
https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512008
]
Malcolm Cleaton commented on LOGGING-114:
-----------------------------------------
Dennis: Commons-logging is entirely in its default configuration, no properties
are provided. Yes, I'm sure commons-logging is the first to initialize log4j.
log4j doesn't print any messages, but it's not the case that it can't find its
configuration file. It finds the file, and fails with a NoClassDefFoundError
while trying to instantiate the appenders specified in the file. The log4j code
doesn't handle this error, so it doesn't print anything, just allows the error
to propagate.
Simon: Yes, I agree that's probably the only fix you can make, although it's
unfortunate that this means the JCL dynamic discovery mechanism can leave
anything it fails to load in a broken state, causing very difficult debugging
later on. In our case, JCL was being used by our client for very basic logging,
so the fact that their logging of our startup error was coming out of the jdk
1.4 logging library rather than log4j made almost no visible difference and was
not noticed. Once we'd ruled out the famous classloader problems early on, it
took quite a while before JCL came back under suspicion - we didn't realise it
could also cause this kind of problem. Better information in the diagnostic log
would indeed be an improvement - but once we'd turned on diagnostics and had
that exception with the bad message, we were very near the end of our debugging
journey.
I've also raised a bug on log4j, suggesting that, since they already print on
stderr when there's no logging configuration, they could also do so when the
clinit of LogManager is about to die:
http://issues.apache.org/bugzilla/show_bug.cgi?id=42855.
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
