[
https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517531
]
Malcolm Cleaton commented on LOGGING-114:
-----------------------------------------
> there is a commons-logging.properties file that tells commons-logging to use
> log4j
This is the difference. In my case there was no such commons-logging.properties
file. I suspect this is what causes a visible error when log4j is unusable.
> 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.
