Hi. My team ship a product which uses custom log4j appenders for integration with a messaging system. Usually everything is very nice. However, we recently hit a nasty problem where one of our customers was using commons-logging on top of log4j. A NoClassDefFoundError was raised, as runtime dependencies of our custom appender were missing, and this error propagated through the static clinit in LogManager. Usually this wouldn't have been so bad, as the exception would have been reported and easy to debug from, but with commons-logging loading log4j, the exception is swallowed and some other logging system is swapped in. Later on, when our code tries to use log4j directly, things are broken internally. LogManager failed to load, so future attempts to reference loggers die with "java.lang.NoClassDefFoundError at org.apache.log4j.Logger.getLogger(Logger.java:117)". When this is the only error you're seeing, it's quite hard to debug what's going on. I suggest that LogManager should do more handling of errors; perhaps it could dump the stack trace to stderr before propagating an unhandled exception or error out of the static initialization block? I've also suggested that commons-logging could behave better here than silently swallowing the NoClassDefFoundError, in https://issues.apache.org/jira/browse/LOGGING-114, but it's uphill. I'm very much hoping one project or the other will agree to a tweak, so that nobody else has to debug from these very confusing messages!
If I understand your issue correctly, your problem is that you WANT to use log4j but the log4j loading inside commons-logging fails due to missing classes. Personally I would suggest you stop using commons-logging and instead use slf4j with the log4j backend (this is a simple compile-time binding without class loader voodoo) and add the commons-logging slf4j module to satisfy your current commons-logging calls. See http://slf4j.org/docs.html for documentation. As an added benefit it gives you the ability to use {} in your log strings as object.toString() placeholders. This allow you to get rid of many logger.isDebugEnabled() calls. See http://slf4j.org/faq.html#logging_performance I do not think that this is a bug in log4j, and certainly not one which warrants adding try-catch stuff to the static init part of LogManager. Please reopen issue if you disagree.