tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject Re: separate log4j configurations
Date Tue, 01 Feb 2005 22:24:24 GMT
Quoting Roberto Cosenza <roberto.cosenza@infoflexconnect.se>:

> If you will configure log4j instances which are in the same classloader,
> they will conflict.
>
>            Bootstrap
>           |
>        System
>           |
>        Common
>       /      \
>  Catalina   Shared
>              /   \
>         Webapp1  Webapp2 ...
>
>
> http://jakarta.apache.org/tomcat/tomcat-5.5-doc/class-loader-howto.html
>
> In other words, your webapp log4j.configuration will override your
> tomcat-wide log4j.configuration which may annoy you
> /roberto

No, Tomcat will continue to log just as it was configured at the server level. 
And, actually, his log4j.properties file in WEB-INF/classes wouldn't even get
picked up by log4j at all because the default logger repository has already
been configured (assuming no manual configuration) so there would be no
auto-configuration triggered.

I think what Tony is looking for is his Test webapp to control logging for
itself.  To do this, he would need to do one of two things...

1.  Place a copy of log4j.jar in WEB-INF/lib.  In a parent-last classloading
environment, such as Tomcat provides, log4j will have its own environment to
log in completely separate from that of the server.

2.  Use a repository selector.  I wouldn't bother with this until Log4j-1.3
comes out, but after that, once can simply define an <env-entry> (when using
the JNDI repository selector) in web.xml to specify that the webapp should log
within a named logger repository separate from the default one which the server
is using.  This is much more flexible because then multiple apps can log to the
same logger repository if they want.  Here one gets all the benefits of #1 but
can also coordinate like-applications to log to the same logger repository
without affecting other logger repositories.  In this case, a single log4j.jar
would be at the server level and not in WEB-INF/lib webapps.


Jake

>
>
> ----- Original Message -----
> From: "Tony Tomcat" <tony.tomcat@gmail.com>
> To: <tomcat-user@jakarta.apache.org>
> Sent: Tuesday, February 01, 2005 8:50 PM
> Subject: separate log4j configurations
>
>
> > Is it safe to have 1 log4j.properties setup for all of tomcat and then
> > override it for a webapp that might need slightly different logging?
> >
> > For example..
> >
> > I place log4j.jar and the Jakarta commons-logging.jar into the
> > $TOMCAT_HOME/common/lib directory and have a log4j properties file in
> > $TOMCAT_HOME/common/classes/log4j.properties
> >
> > This properties file writes to ${catalina.home}/logs/all.out
> >
> > Then I have a test webapp that I want in its own log4j output file so
> > I install a new log4j.properties file in that webapp.
> >
> > $TOMCAT_HOME/webapps/test/WEB-INF/classes/log4j.properties
> >
> > This properties file puts the output in ${catalina.home}/logs/test.out
> >
> > This appears to work but I'm just wondering if this is the correct way
> > to go about it.
> >
> > The reason I want my main logging configuration in common/classes is
> > because I want my operations team to control the logging instead of
> > the war file.   In the case of my test application I always want it to
> > log at the debug level and it is only installed in production briefly
> > so having the log4j.properties in the war file is fine and allows me
> > to keep it logging at debug even if the other apps are at WARN.
> >
> > Any issues here?
> > Tony
> >
> > ---------------------------------------------------------------------
> > 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