You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Apache Wiki <wi...@apache.org> on 2005/06/08 01:04:48 UTC
[Jakarta-commons Wiki] Update of "Logging/FrequentlyAskedQuestions" by
SimonKitching
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" for change notification.
The following page has been changed by SimonKitching:
http://wiki.apache.org/jakarta-commons/Logging/FrequentlyAskedQuestions
The comment on the change is:
Added info about fixing memory leaks on webapp undeploy
------------------------------------------------------------------------------
"getLogger" method that returns the real underlying object. However in most cases this is not necessary, as initialisation/shutdown
methods need to be invoked on "the logging library as a whole" rather than the objects representing individual logging categories.
+ == A memory leak occurs when undeploying/redeploying a webapp that uses Commons Logging. How do I fix this? ==
+
+ When commons-logging is deployed in a "shared" classloader that is visible to all webapps, commons-logging still ensures that each
+ webapp gets its own logging configuration by setting up a separate !LogFactory object for each context classloader, and ensuring that
+ the correct !LogFactory object is used based on the context classloader set whenever !LogFactory.getLog is called.
+
+ However the negative side of this is that !LogFactory needs to keep a static map of !LogFactory objects keyed by context classloader;
+ when the webapp is "undeployed" this means there is still a reference to the undeployed classloader preventing the memory used by
+ all its classes from being reclaimed.
+
+ The commons-logging-optional.jar optional code provided with commons-logging 1.0.4 attempted to address this issue using weak references,
+ but this approach cannot solve the issue in many cases.
+
+ The correct solution in the case of a webapp is for the webapp to include a class which implements !ServletContextListener:
+
+ {{{
+ class ContextManager implements javax.servlet.ServletContextListener {
+ public void contextDestroyed(ServletContextEvent sce) {
+ ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
+ LogFactory.release(contextClassLoader);
+
+ // optionally, clean up the underlying concrete logging library too
+ }
+ }
+ }}}
+
+ The deployment descriptor for the webapp then needs to be updated to specify that the above class should receive context change callbacks.
+
----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org