tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Naresh Bhatia" <>
Subject RE: Modifying Tomcat's classpath
Date Sat, 03 May 2003 12:59:54 GMT
Hi Jake,

I have gone with your suggession to put log4j.jar in WEB-INF/lib and
log4j.xml in WEB-INF/classes. This works well when I deploy the solution
as a war file in Tomcat. I do have one additional question for you. What
be your suggestion in case of ear files where there may be multiple
webapps, EJBs and simple jars all packaged into one file. Is there
a way to share one copy of log4j.jar and log4j.xml? Also is it advisable
to share these between ear components?


-----Original Message-----
From: Jacob Kjome [] 
Sent: Thursday, May 01, 2003 10:35 AM
To: Tomcat Users List
Subject: RE: Modifying Tomcat's classpath

Oh, and you can't put log4j.xml in common/lib.  Put it in 
common/classes.  Only jar files in common/lib are put in the classpath.


At 09:33 AM 5/1/2003 -0500, you wrote:

>If you use the servlet context's log() method, then you are at the 
>of whatever Tomcat uses for logging.  I use this only for information 
>specific to stuff like servlet initialization.  I use log4j totally 
>separately from this.  The servlet context logging is not meant to be 
>robust and flexible.  That is where log4j comes in.  Use it for general

>application logging.
>Also note that when you use log4j in common/lib, every time any app 
>log4j configures itself, it will override the configuration for *all*
>unless you use a custom logger repository selector which provides a
>logging environment for each app.   The simple solution is to put 
>log4j.jar in each webapp's WEB-INF/lib and a log4j.xml or 
>in WEB-INF/classes for default initialization.  You might argue, "well 
>I'll only have one app configure log4j and the rest won't have a config

>file, so it won't override anything".  I'd answer this by saying that
>cannot control this very well.  There are some projects that distribute

>jars which a properties file in the jar.  Log4j may find these and use 
>them.  I wouldn't trust putting log4j in common/lib without at custom 
>repository selector.
>At 09:31 AM 5/1/2003 -0400, you wrote:
>>Thanks Jake. I will start looking at this. In the meanwhile, I have a 
>>question. As a temporary solution, I have been able to direct my web 
>>apps to use log4j by putting a copy of log4j.jar and log4j.xml in 
>>CATALINA_HOME/common/lib (as you suggest below). However, the Tomcat 
>>Engine and the Host are still using 
>>org.apache.catalina.logger.FileLogger (as configured in server.xml). 
>>Is there a way to direct these to log4j?
>>-----Original Message-----
>>From: Jacob Kjome []
>>Sent: Thursday, May 01, 2003 9:12 AM
>>To: Tomcat Users List
>>Subject: RE: Modifying Tomcat's classpath
>>I'd suggest that you have individual log4j.xml files for each webapp 
>>either put log4j.jar in WEB-INF/lib or share it across all apps by 
>>putting it in CATALINA_HOME/common/lib.  Of course, doing the latter 
>>makes it so
>>that each webapp gets it config overridden each time a webapp is 
>>configured.  The solution is to use a custom repository selector which

>>facilitates the use of separate logger repositories.  You can read 
>>that here:
>>I've implemented a standard InitContextListener + some custom 
>>selectors which will allow you to make this simple in a webapp and 
>>provide full control over where files get written (if using a file 
>>appender) via
>>web.xml configuration.  Each log4j.xml can use environment variables 
>>to dynamically use the logging path given in web.xml.  Furthermore, 
>>you can
>>override the web.xml <context-init> parameters via <Parameter> 
>>elements nested in <Context> elements.  This gives the deployer full 
>>control without having to modify anything inside the webapp.
>>You can find all this in the jakarta-log4j-sandbox CVS repository. 
>>View the javadoc for those files to find out how to use them.  The 
>>javadoc is pretty detailed.  Use the build to generate the selector 
>>and servlet jars.  When you use them, make sure you put the selector 
>>jar wherever you
>>put the log4j.jar and put the servlet jar in you WEB-INF/lib.
>>At 08:27 AM 5/1/2003 -0400, you wrote:
>> >Thanks Tim. Your comments make complete sense to me. Time to look at

>> >JNDI :-).
>> >
>> >-----Original Message-----
>> >From: Tim Funk []
>> >Sent: Thursday, May 01, 2003 7:56 AM
>> >To: Tomcat Users List
>> >Subject: Re: Modifying Tomcat's classpath
>> >
>> >
>> >inline ...
>> >
>> >Naresh Bhatia wrote:
>> > > 1) I like to keep my log4j.xml configuration file common to all 
>> > > web apps. In fact I would like Tomcat to be using log4j and my 
>> > > configuration file (haven't found a way to do this yet).
>> >You can also create anc drop it in WEB-INF/classes 
>> >and
>> >each webapp gets its own loggin config. (Disclaimer: I haven't 
>> >extensively used this yet but thats what the log4j docs say, but 
>> >then again - I am
>> >a
>> >massive shift to commons-logging)
>> >
>> > > 2) I have a read/write "data" directory that I need several 
>> > > webapps to
>> >
>> > > have access to, via the classpath - getResourceAsStream(). It 
>> > > does not
>> >
>> > > feel right to put this data directory in WEB-INF/classes or 
>> > > WEB-INF/lib.
>> >Thats because it should not feel right. A better(?) way is to do 
>> >this is
>> >
>> >JNDI. That way, the JNDI environment can be setup in server.xml and 
>> >can
>> >be altered by a sysadmin when your data directory needs moved. You 
>> >can also
>> >
>> >create your own JNDI factories (for any complexity you want) or if 
>> >you are depending on a (relative) directory structure, you can just 
>> >populate a String value in your JNDI namespace which would just be 
>> >String value that is the
>> >name of a directory path to the root of your relative repository. Of
>> >course
>> >that being said - rewriting code to do this is a PITA if you already
>> >have a
>> >working application.
>> >
>> >
>> >The more classes you place "closer" to the system classloader, the 
>> >harder it becomes to make your system highly available and (more
>> >important) stable. The
>> >multiple classloader scheme is meant to allow each webapp to have 
>> >its own version of libraries so competing version of the same jar 
>> >can
>> >
>> >exist in a single JVM. And upgrades to libraries can be an isolated 
>> >event to a single webapp without introducing regression issues to 
>> >other
>> >webapps.
>> >
>> >-Tim
>> >
>> >
>> >
>> >--------------------------------------------------------------------
>> >-
>> >To unsubscribe, e-mail:
>> >For additional commands, e-mail:
>> >
>> >
>> >--------------------------------------------------------------------
>> >-
>> >To unsubscribe, e-mail:
>> >For additional commands, e-mail:
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message