Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Date: 5 Aug 2004 19:37:01 -0000
Message-ID: <20040805193701.24194.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: tomcat-dev@jakarta.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 27371]  -
    java.lang.ThreadDeath caused by log4j when reloading Tomcat app

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 yoavs@computer.org  2004-08-05 19:36 -------
--- Begin Text by Craig McClanahan ---
The reason that LogFactory instances are stored in a map keyed by
context class loader was to meet a functional requirement that each
webapp could have independently configured constellations of Log
instances, created by independent LogFactory instances, per webapp --
even if commons-logging.jar itself is installed into a shared class
loader (i.e. common/lib or shared/lib in Tomcat).  This is why you
can't just use a static variable, because there would only be one
LogFactory instance across the entire Tomcat JVM.  In addition, there
is no other reasonable key that is specific to a webapp, but *not*
specific to the Servlet API (tying commons-logging use to require
servlet.jar would not be a good thing).

In order to allow cleanup of these allocated instances, the
LogFactory.release() method may be used to ask a LogFactory to release
all of its Log instances.  In addition, the static
LogFactory.release(ClassLoader) method releases references to the
LogFactory instance for that class loader.  I believe that both of
these APIs were just added in 1.0.4.

Inside Tomcat, then, a webapp using c-l can add a
ServletContextListener whose contextDestroyed() method calls the
appropriate release methods to clean up.
--- End text by Craig McClanahan ---

So to the people who reported this: please try adding such a 
ServletContextListener and using the above methods that Craig mentioned, and 
let us know if that makes the error go away.

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