[
https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511699
]
Malcolm Cleaton commented on LOGGING-114:
-----------------------------------------
Hi Dennis.
Yes, log4j does usually tell you when it cannot load its configuration. In this
case it tells me through a NoClassDefFoundError when runtime dependencies fail
to load during configuration loading. If commons-logging is not in use, the
error is easy to understand and quickly fixed.
Unfortunately, if commons-logging is the first to try to load log4j, the error
is swallowed silently. Since it is a problem during the clinint of the
LogManager class, log4j is now broken internally and will not give good errors
again - any future use gets incomprehensible errors. What's more, if
commons-logging diagnostics are enabled, the diagnostic error is logged with
most of the information missing. But I'm repeating myself here, all this is in
the bug report, along with the actual messages involved.
To understand my problem, imagine the other side of it, which will probably
shortly be happening - imagine my attempts to file a bug in log4j on the basis
that, if a class can't be found during configuration loading, they simply allow
the NoClassDefFoundError to propagate. How is that wrong?
But if you're adamant that silently swallowing this error is also not wrong,
it's not their problem and it's not your problem. Where does that leave the
user? I guess it's just my problem.
> 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]
