[EMAIL PROTECTED] wrote:
luehe       2005/02/17 09:55:24

Modified: catalina/src/share/org/apache/catalina/core
StandardContext.java
Log:
Removed potential WebappClassLoader leak.
Consider the following example scenario:
- Servlet class references RequestDispatcher.
- Servlet is loaded. Any of the symbols referenced will be
resolved lazily.
- Servlet is invoked. Thread's context classloader has been set to the
servlet's WebappClassLoader.
- org.apache.catalina.core.ApplicationDispatcher is loaded, and its
static "log" variable is initialized as follows:
private static Log log = LogFactory.getLog(ApplicationDispatcher.class);
- LogFactory.getLog() causes the context classloader (which corresponds
to the WebappClassLoader) to be cached in its static "factories"
Hashtable, as follows:
if (classLoader != null && factory != null)
factories.put(classLoader, factory);
Right now, this classloader is never removed from this Hashtable when the
webapp is stopped.
Depending on number of deployed webapps and their servlets' execution
paths, different Catalina classes will be loaded on different servlet
invocation threads, and the classes' "log" initialization will cause
the threads' context classloaders to be cached in LogFactory and never
released from it.
This patch should fix the issue.
Let me know if you see any problems.

There's the same code (and more) in WebappClassLoader.stop():

        // Clear the classloader reference in common-logging
        org.apache.commons.logging.LogFactory.release(this);
        // Clear the classloader reference in the VM's bean introspector
        java.beans.Introspector.flushCaches();

IMO, it's the right place to do this kind of cleaning up in the classloader, since it's CL related.

So -0 for this.

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to