[Jakarta-commons Wiki] Update of "Logging/FrequentlyAskedQuestions" by SimonKitching

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[Jakarta-commons Wiki] Update of "Logging/FrequentlyAskedQuestions" by SimonKitching

Apache Wiki
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:

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: [hidden email]
For additional commands, e-mail: [hidden email]