[
https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed LOGGING-114.
-----------------------------------
Resolution: Duplicate
Fix Version/s: 1.1.1
Assignee: Dennis Lundberg
> 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
> Assignee: Dennis Lundberg
> Priority: Minor
> Fix For: 1.1.1
>
>
> 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.