[jira] Commented: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
[ https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512008 ] Malcolm Cleaton commented on LOGGING-114: - Dennis: Commons-logging is entirely in its default configuration, no properties are provided. Yes, I'm sure commons-logging is the first to initialize log4j. log4j doesn't print any messages, but it's not the case that it can't find its configuration file. It finds the file, and fails with a NoClassDefFoundError while trying to instantiate the appenders specified in the file. The log4j code doesn't handle this error, so it doesn't print anything, just allows the error to propagate. Simon: Yes, I agree that's probably the only fix you can make, although it's unfortunate that this means the JCL dynamic discovery mechanism can leave anything it fails to load in a broken state, causing very difficult debugging later on. In our case, JCL was being used by our client for very basic logging, so the fact that their logging of our startup error was coming out of the jdk 1.4 logging library rather than log4j made almost no visible difference and was not noticed. Once we'd ruled out the famous classloader problems early on, it took quite a while before JCL came back under suspicion - we didn't realise it could also cause this kind of problem. Better information in the diagnostic log would indeed be an improvement - but once we'd turned on diagnostics and had that exception with the bad message, we were very near the end of our debugging journey. I've also raised a bug on log4j, suggesting that, since they already print on stderr when there's no logging configuration, they could also do so when the clinit of LogManager is about to die: http://issues.apache.org/bugzilla/show_bug.cgi?id=42855. 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]
[jira] Commented: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
[ 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]
[jira] Commented: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
[ https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511709 ] Joerg Schaible commented on LOGGING-114: IMHO this is really a JCL problem. It detects log4j and tries to use it. It is fine that it searches for something else if log4j is not present. But here it even suppresses a thrown Error that indicates also a problem for JCL. From user's PoV either the presence of log4j was not expected at all, he failed to configure to Log4J or he failed to configure JCL. In any case he must realize that something is not working as expected. 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]
[jira] Commented: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
[ 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]
[jira] Commented: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
[ https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511880 ] Dennis Lundberg commented on LOGGING-114: - Malcolm, Just so I understand your setup fully: Do you configure commons-logging in any way? Either via a system property or through the use of a commons-logging.properties file? If yes, please tell us how. Do you get any message from log4j, saying that it couldn't find its configuration file? If yes, what does it say. Are you sure that your code that uses commons logging is the one that causes log4j to be loaded? Or could it be that the other library of yours, that use log4j directly, is the first user? 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]
[jira] Commented: (LOGGING-114) Silent Swallowing of NoClassDefFoundError
[ https://issues.apache.org/jira/browse/LOGGING-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511556 ] Dennis Lundberg commented on LOGGING-114: - It is not the job of commons-logging to report on errors regarding the underlying logging implementations failure to configure itself. Commons-logging tries its best to send the messages, that the author of a library wants to log, to the logging implementation. Which logging implementation commons-logging sends these messages to is either A. configured in commons logging explicitly or B. found dynamically There is no way for the underlying logging implementation to tell commons-logging anything. So if the underlying logging implementation cannot configure itself correctly, as I understand is your situation here, commons-logging can't do much about it. It is the job of log4j, in this case, to tell you that it cannot load its configuration and from my experience it usually does. 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]
