Websphere 5.1 TrLogFactory issue with Spring 2.0

[mattdenner]

We're using Spring 2.0 and deploying our application under both JBoss and Websphere. When deploying under Websphere we are seeing the following error:

Caused by: org.apache.commons.logging.LogConfigurationException: The
chosen LogFactory implementation does not extend LogFactory. Please
check your configuration. (Caused by java.lang.ClassCastException:
com.ibm.ws.commons.logging.TrLogFactory)
       at
org.apache.commons.logging.LogFactory.createFactory(LogFactory.java:1200)
       at org.apache.commons.logging.LogFactory
$2.run(LogFactory.java:994)

This, we think, is because Spring 2.0 uses commons-logging 1.1 but Websphere includes an older, incompatible, version of this code. I've seen numerous posts about deleting a JAR from the Websphere installation but this is not an option for our users.

What can be done to either solve or workaround this issue?

[cwash5]

In WebSphere after you deploy your application you can change the classloader policy to PARENT_LAST. This will use the commons-logging packaged with you application instead of the one with WebSphere. You might need to change this on both the EAR and WAR level. If you are using WebSphere 6.x this can be done on the Enhanced ear through the deployment tab in RSA 6.0.

This essentially ensures that your application is using jars packaged with your app (EAR or WAR) before it tries to use ones included in WebSphere.

Hope that helps....

[Costin Leau]

Try also searching the forum - I recall various posts on the matter a while ago (6+ months).

[pgras]

Hello,

I also have a lot of problems with commons-logging and WebSphere (5.1). These problems have nothing to do with Spring, but because of these problems I cannot see the logs from Spring

To understand the problem you can have a look at the ws-commons-logging.jar in WebSphere, it contains a 'commons-logging.properties' file that configures commons-logging in a WebSphere specific way

After trying a lot I finally changed the Spring code to use Log4J instead of commons-logging. Now our application is stable enough and we migrated to the original Spring 2.0.1 because we can live without the Spring logs.

Note: I didn't want to use parent-last classloader delegation just to solve a logging problem.

For your problem I think you should try to bundle your application with some 'light' version of commons-logging.jar (I don't remember which one it is, perhaps commons-logging-api.jar ???)

Hope this helps
-Patrick

[Costin Leau]

commons-logging-api.jar is indeed one solution or slf4j. It provides a jar called jcl104-over-slf4j which implements the commons logging API so you can still use it with the existing code but it delegates to slf4j which uses compiled wired logging api instead of runtime-through-classloader discovery.
Take a look at their site - it provides some nice documentation on how you can migrate from commons-logging to slf4j.

[mattdenner]

We're using Spring 2.0 and deploying our application under both JBoss and Websphere. When deploying under Websphere we are seeing the following error:

Thanks for all of the replies. We decided to go down the path of removing the commons-logging and log4j JARs from our EAR and leaving it to the customer. Instead we are documenting how we suggest they do the logging if they want it (by putting the JARs back into the WAR, setting the classloader mode to PARENT_LAST on the web module, and ensuring that there is a commons-logging.properties file in the WAR classes directory).

[sonugopal]

The same problem is applicable to both WAS 5.x and 6.0. The reason is that IBM provides its own LogFactory and Log implementation - TrLogFactory and TrLog. If you open the was_root/lib folder, there is ws-commons-logging.jar which contains these two files, it also contains a commons-logging.properties.

This is the reason, why you need to change the delegation to PARENT_LAST for the system to read commons-logging.properties that is provided in lets say in WAR.

However there is a workaround, you can use the commons-logging-adapter.jar released in commons-logging 1.1. Place this jar in the WAR along with your log4j jar. Also you need to specify the LogFactory implementation in a file at META-INF/services folder (JCL discovery option 2).

With this approach your application and spring should be able to log successfuly irrespective of the delegation model. I know some of the users here may have a concern in using a different JCL versions.

Any workaround that involves commons-logging.properties would involve a change in delegation model.

You can also use the jcl-over-slf4j option, your application can code to JCL interfaces but all the logging requests would be delegated to Slf4j (refer to Slf4j site). However this solution does not provide correct support for log4j conversion parameters like %C and %M.

[davsclaus]

Yes WebSphere is a pain in the ass with getting logout from 3. party libs using commons-logging.

I remember fighting with this 1+ year ago on a 5.1 box. Eventually I gave up. I remember finding some 20+ long pdf pages at IBM websites documenting how you could get it to work. But nothing worked.

To bad its still a problem in the 6.x lines as some of our clients use WebSphere so we are stuck on this hmmmm developer unfriendly app server.

Good luck.