I’m currently running several web apps from one Tomcat instance and they share several libraries that require log4j logging, Sitemesh, for instance. For this reason, I removed log4j.jar from each of my webapp’s “lib” folders and placed it instead in “${catalina.home}/lib” (note that I’m using Tomcat 6. This would be “${catalina.home}/common/lib” in earlier Tomcat versions)
I didn’t realise that this would create a a myriad of problems. What I found was that in my test environment, logging for all webapps ended up going to the log file for one particular webapp, while in my staging environment logging for all webapps went to the log file for a totally different webapp.
It took some time, but ultimately I got to the bottom of it. Apparently log4j does not play nice when the same log4j.jar is being used by multiple webapps. Configuring the rootLogger for one webapp appears to overwrite rootLogger settings for another webapp if log4j.jar is shared. Since each of my webapps was configuring the rootLogger to append to a different particular file, this meant that all logging ended up in only one file.
To circumvent the issue, log4j.jar must be place in each individual webapp’s “lib” folder in addition to Tomcat’s common library folder. Additionally, your web apps must be configured to use their own class loaders before using the parent class loader. This was my stumbling block. Your Tomcat context containers need to be set up something like:
<loader delegate=“false”/>
</Context>
If delegate is set to true then each webapp loads the common log4j.jar in favour of its own log4j.jar, giving rise to the problem.
With Tomcat 5.5, log4j.jar should be placed in shared lib folder. It works like a charm.
With Tomcat 6, you must place it in each webapp (http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html)