RSA 7.0.0.3/WAS 6.1.
Apache Commons Logging has a problem with WAS 6.1. Its Log4JLogger either can't be loaded or be reported not compatible with LogFactory.
The root cause is WebSphere uses commons-logging and so it's in the root classloader. In addition, WebSphere ships a commons-logging.properties with the following properties set:
org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger
Therefore by default the application will use JDK logging and not log4j. The solution is to ensure that the right classloader mode is set and the application has an appropriate commons-logging.properties:
Set application classloader mode as PARENT_LAST. Also, add a commons-logging.properties to the application classpath with the following entries:
priority=1
org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl
The priority flag was introduced in Commons Logging 1.1 to allow an ordering based on priority. To ensure that an application's commons-logging.properties will take precedence over WebSphere's file, a priority of greater that 0.0 must be set.
Tuesday, January 08, 2008
Subscribe to:
Post Comments (Atom)
4 comments:
I'm trying this and not having any luck. I've got the file in the WEB-INF/classes of the two WAR files in my EAR. Does it need to be in the EAR classpath somehow? If I don't run as PARENT_FIRST I get an error about incompatible classes (Log4JLogger doesn't implement Log) When I run PARENT_LAST I get the same thing.
Any help is much appreciated.
Jason Henriksen
Guess I was just lucky, but that solution had worked for me.
I didn't put anything in the EAR classpath, all in WAR.
Wish you good luck.
Just found out the common logging need to be version 1.1.
Found another conclusion for the problem:
http://www-01.ibm.com/support/docview.wss?uid=swg24019662
Stephan Wussler
Post a Comment