logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
Date Fri, 19 Mar 2004 15:41:15 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=27371>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=27371

java.lang.ThreadDeath caused by log4j when reloading Tomcat app





------- Additional Comments From hoju@visi.com  2004-03-19 15:41 -------
Yaan, are you saying that the ThreadDeath message still contains references to
Log4j in the stack trace after using LogManager.shutdown()?  Or does it now look
like it is coming from something else?  Do you (or any other libraries in your
app) start threads in your app that you don't clean up at application shutdown?


Marc, same question to you.  Furthermore, LogManager.shutdown() shuts down the
LoggerRepository connected to the current running application.  This is decided
based on the type of repository selector being used.  You are correct that, by
default, the default logger repository is used and if LogManager.shutdown() is
used without havin used a custom logger repository selector, it will shut down
logging for all applications using that logger repository.  However, there are
two ways to avoid this affecting other apps....

1.  Put log4j.jar in WEB-INF/lib which automatically scopes the default logger
repository to the current webapp, not to the rest of the server.  This is thanks
to Tomcat's implementation of servlet spec recommended classloading behavior
where the WebappClassLoader is checked first for libraries to load rather than
using normal Java2 classloading behavior where the parent classloader would be
checked first.  Do this for all of your apps and you will have complete logging
separation without taking any further steps.

2.  Use a custom repository selector.  This will provide for a separate logger
repository based on, for instance, each app's JNDI context or Classloader.  Read
more about this here....
http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/AppContainerLogging

Using this, you can have a single instance of Log4j at the server level which is
also avialable to all applications and all logging will be separated for all. 
As such, LogManager.shutdown() calls will only affect the application it was
called from.


Jake

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message