tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject RE: Modifying Tomcat's classpath
Date Thu, 01 May 2003 14:35:14 GMT

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.

Jake

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

>If you use the servlet context's log() method, then you are at the mercy 
>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 using 
>log4j configures itself, it will override the configuration for *all* apps 
>unless you use a custom logger repository selector which provides a unique 
>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 log4j.properties 
>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 you 
>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.
>
>Jake
>
>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?
>>
>>Thanks.
>>Naresh
>>
>>-----Original Message-----
>>From: Jacob Kjome [mailto:hoju@visi.com]
>>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 and
>>
>>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 about
>>
>>that here:
>>http://www.qos.ch/logging/sc.html
>>
>>I've implemented a standard InitContextListener + some custom repository
>>
>>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.
>>http://jakarta.apache.org/site/cvsindex.html
>>
>>See:
>>http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/
>>log4j/selector/
>>
>>and
>>http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/
>>log4j/servlet/InitContextListener.java
>>
>>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.
>>
>>Jake
>>
>>
>>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 [mailto:funkman@joedog.org]
>> >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 log4j.properties 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
>>making
>> >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
>>peacefully
>> >
>> >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: tomcat-user-unsubscribe@jakarta.apache.org
>> >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>> >
>> >
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>> >For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message