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:33:14 GMT

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