tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Naresh Bhatia" <NBha...@sapient.com>
Subject RE: Modifying Tomcat's classpath
Date Thu, 01 May 2003 13:31:52 GMT
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
View raw message