I think Websphere 5.x makes life too hard for using Jakarta Commons Logging (See Here). What do you think ? How about using Log4j directly so the logger behavior is more predictable ?

Anyhow, at least for development purposes, adding the system property:

-Dorg.apache.commons.logging.LogFactory=
org.apache.commons.logging.impl.LogFactoryImpl

will force Websphere to use the normal commons logging implementation instead of it's own.

log4j and WSAD

Also, to configure log4j properly for EJB project in WSAD 5.x, not only does log4j.xml need to be in the Java Build Path of the EJB project, the folder containing the log4j.xml must also be under the EJB project. Interestingly this is not necessary for a non-EJB project.

For example, for a non-EJB project PA, I can reuse an existing folder PB/F containing log4j.xml of a different project PB by setting the folder PB/F as a class folder of PA. This works if and only if PA is a non-EJB project.

Just realized a better alternative to the build path approach is to set up an independent Java project with a log4j folder as a class folder in the Java project's build path. Include the Java project as part of the EAR of the EJB project, and set the jar file dependency of the EJB project to depend on the Java project.