commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: FW: log4j SEVERE ThreadDeath in Tomcat 5.0.25
Date Thu, 05 Aug 2004 19:20:45 GMT
On Thu, 5 Aug 2004 10:49:36 -0400, Shapira, Yoav <> wrote:
> Hola,
> I'm forwarding this to commons-dev to include the commons-logging developers on this
discussion.  What do you guys think?  Is there another readily available key to use when caching
LogFactory objects?  Or perhaps a way for commons-logging to not cache these, or maybe discard
the cache when a webapp (or its classloader, more likely) is shut down?

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.

> Yoav Shapira
> Millennium Research Informatics

Craig McClanahan

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message