[
https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511853
]
Simon Kitching commented on LOGGING-114:
----------------------------------------
JCL has adopted the principle that logging problems should never stop an app
from running. In the past exceptions from logging libs were allowed through JCL
in some cases and there were loud user complaints. In many cases, the users
didn't actually *want* logging output anyway, and didn't know how to fix the
logging problems because they were complex and involved classloaders with
different classpaths etc. So now, JCL *never* fails to init. In particular, if
log4j is present but cannot be initialised (eg due to classloader problems) JCL
quite deliberately ignores this problem and lets the app start.
If someone really does want logging output but aren't getting what they expect
*then* they can turn on JCL diagnostic output to see what's happening.
I don't think there is likely to be agreement for any change to JCL's behaviour
for this.
Writing problems stuff to stdout etc is also unacceptable when diagnostics are
not enabled. Again, this can cause problems for users who don't actually care
about logging output anyway.
However I would agree that when diagnostics are enabled, JCL should write out
the message from the original exception. If it's not doing this then I would
call that a bug.
> 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]
