On Thu, 5 Aug 2004 10:49:36 -0400, Shapira, Yoav <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
