[jira] Commented: (LOGGING-114) Silent Swallowing of NoClassDefFoundError

["Dennis Lundberg (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517208 ] 

Dennis Lundberg commented on LOGGING-114:
-----------------------------------------

I'm going to try to set up a test case for this issue. Do you think that this setup would reproduce this problem:

* Create a small java class that uses commons logging
* Put log4j in the class path
* Put a valid configuration for log4j in the class path, that tries to use an smtp appender, which requires activation.jar and mail.jar to be present in the class path
* Do not put activation.jar and mail.jar in the class path
* Log a message using commons logging

After this do I also need to
* call log4j directly?

> 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.