tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: Issues changing log4j levels for tomcat web apps
Date Thu, 17 Jun 2010 19:47:54 GMT
On 17.06.2010 19:44, Jeffrey Nguyen (jeffrngu) wrote:
> This question might be a little off topic, but I thought since it
> involved tomcat web apps, I figured someone might know the answer.
>
> I have Liferay EE 5.2.6  running on top of tomcat 6.0.26.   Liferay has
> an admin GUI page to allows me to change log level settings for
> different packages.  The issue I'm facing is changing the log levels
> seems to only take effect on the ROOT web apps.  All the other plugin
> web apps do not seem to response to the new log levels.   I checked on
> Liferay support forums and found that others are also facing this
> problem
> (http://www.liferay.com/community/forums/-/message_boards/message/492284
> 1)
>
> Is this really Liferay's specific problem or is it Tomcat issue in
> general?
>
> In plain vanilla Tomcat, are the web apps loaded in a WebAppClassLoader
> and ROOT web app is loaded by StandardClassLoader?  If so, I assume this
> is really just an issue with Tomcat right?  How do I get around this
> problem?
>
> In a previous project I worked with, we relied on DB change notification
> to relay the new log level to all tomcat web apps.  However, I don't
> want to consider that solution because it requires design changes and it
> has its own set of problem.
>
> Any pointers would be much appreciated!  Thanks in advance!

The root context isn't special with respect to class loading. Each 
context has its own webapp classloader. What that means with respect to 
log configuration depends on the log frameworks used by the web 
applications, and how the frameworks are deployed. Often the webapps for 
example use log4j and each webapp contains a copy of the log4j jar file. 
That means each webapp would have its own copy of log4j and a completely 
independent configuration.

If log4j would instead be deployed *only* via a shared loader (like the 
common loader), then all webapps would share a single instance and a 
single configuration.

You can force log4j (example) to use a common configuration for all 
instances during startup by using the -Dlog4j.configuration=SOMEURL 
commandline parameter, but that doesn't help with later dynamic changes.

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message