In my solution, I am using Log4J inside an EJB. I created a log4j.properties file and put it on the classpath of my EJB. I created a file appender for some exception cases. When I ran my solution, I found that my file wasn’t being created. Upon further inspection, my log4j.properties file was not being loaded at all.

Google provided a lot of links to people complaining of the same problem with some wacky solutions. This is apparently a very easy problem to solve when you have a WebProject as the META-INF/lib directory goes directly into the classpath as the first resource. Files that are placed there get resolved first.

This logging issues seemed to be more prevalent in WebSphere v5 as most links were old and referring to that version of the runtime. I figured that this problem has something to do with the classloader and likely that I need to override something to get my own logger running instead of WebSphere’s.

Luckily, I ran across:

Integrating Jakarta Commons Logging which discusses the issues of the classloader and what you can do to get around it. It’s still focused on the v5 product.

Next, I somehow stumbled into the WebSphere v6 infocenter. The infocenter contains a great set of articles outlining exactly what you need to do to get your own log4j configuration working:

• Configuring applications to use Jakarta Commons Logging
• Jakarta Commons Logging
• Configurations for the WebSphere Application Server logger

The summary is to drop a file named:

org.apache.commons.logging.LogFactory

into the

META-INF/services

directory in your EJB.

The file contains (on a single line):

org.apache.commons.logging.LogFactory
=org.apache.commons.logging.impl.Log4jFactory

Now the log4j.properties will be picked up from your applications classpath first!

Happy Logging!