Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <f8b39ace04080512203e0407d0@mail.gmail.com>
Date: Thu, 5 Aug 2004 12:20:45 -0700
From: Craig McClanahan <craigmcc@gmail.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: FW: log4j SEVERE ThreadDeath in Tomcat 5.0.25
In-Reply-To: <9C5166762F311146951505C6790A9CF80229BE0A@US-VS1.corp.mpi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <9C5166762F311146951505C6790A9CF80229BE0A@US-VS1.corp.mpi.com>

On Thu, 5 Aug 2004 10:49:36 -0400, Shapira, Yoav <yoav.shapira@mpi.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org