Commons Logging with Jboss - Can Never be a good Choice

If you are planning to use commons-logging and that too with Jboss and I would suggest you to re-think about it.

Let me share with you some of horrfying experience: -

Our Application is preety big and is using Log4j(with some customization) for all sorts of debugging/ error messages.
Some of our new Enhancements require Rich GUI components and without giving a second thought we decided to use JSF - A mix of Apache myFaces and Jboss Rich faces.

As all other open sources do myfaces/ richfaces also used commons logging to log the messages and gave us the option to configure those logs by simply putting up a property file in the WEB-INF/classes directory of our application.

We did the same and added a commons-logging.properties file at the required location with an addition to our WEB-INF/lib directory (commons-logging.jar1.0.2).

Though our application was deployed as an ear but having successfully configured it with war file we never thought that deploying it with ear will be a nightmare.

As soon as we tried to deploy our application (packaged in a ear) on development boxes, we encountered a very strange exception while starting up of the application.

Exception in thread "main" org.apache.commons.logging.LogConfigurationException: \
org.apache.commons.logging.LogConfigurationException:
No suitable Log constructor [Ljava.lang.Class;@12b66 for org.apache.commons.logging.impl.Log4JLogger
Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category)
Caused by org .apache.commons.logging.LogConfigurationException:
No suitable Log constructor [Ljava.lang.Class;@12b6651 for org.apache.commons.logging.impl.Log4JLogger

We thought there might be a version mismatch or different versions of commons-logging.jar file loaded within our application.
We were shocked to see that there is no other version of commons-logging.jar file installed in our application and than suddenly we realized that Jboss uses commons-logging.jar file,
but this info made our work more difficult because as per our application classloader policy it should pick up our jar file and not the one which packaged with Jboss.

At last we found that there is some serious bug in Commons-logging which prevents the multiple copies (though they are of same version) of the jar file to be loaded within the same classloader.

And to make it worse what Jboss does that irrespective of the value of "java2ParentDelegation" it first picks up the commons jar file from its \lib directory and now if any of the child classloaders tries to loads the jar file from the application lib directory the commons-logging.jar file throw an weird exception.

The Only solution available to this is that you have to use JBOSS commons-logging.jar file, Having no other way we simply removed the commons-logging.jar file from our application lib directory.

Here is the link which can give you further information about this BUG in commons-logging.

http://www.qos.ch/logging/classloader.jsp

Again I remember one of my dearest friends words "Open Source Software are never for free"