https://issues.apache.org/bugzilla/show_bug.cgi?id=50858
Summary: Classloader leak when using Log4j in a webapp
container such as Tomcat, WebLogic
Product: Log4j
Version: unspecified
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Appender
AssignedTo: [email protected]
ReportedBy: [email protected]
This is possibly redundant with bug #46221, however, different classes and
libraries appear to be involved, so I am submitting this anyways.
I have implemented a trivial "Hello World" Web Application, which invokes
"LogManager.getLogger(HelloServlet.class)". Demonstrating the classloader leak
is a little cumbersome, I apologize, but here are the steps:
1. Deploy the attached "simple.war" to the web container of your choice (I
used Tomcat v6.0.29)
2. Navigate to http://localhost:8080/simple; you should see a "Hello, world!"
message. A warning will also be logged that log4j was not instantiated
properly.
3. Undeploy "simple.war".
4. Using jps/jmap/jhat, view the heap dump of your web container. View
references to the WebAppClassLoader, excluding weak references. You will see
that the WebAppClassLoader still has static references from about a dozen Log4j
classes, such as org.apache.log4j.Category and org.apache.log4j.Priority.ERROR.
I also implemented a ServletContextListener to call LogManager.shutDown() and
Introspector.flushCaches(), following advice from
http://marc.info/?l=log4j-user&m=109585865720819. This didn't solve the
problem. The only way I could resolve the ClassLoader leak was to remove all
references to LogManager.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
