[jboss-jira] [JBoss JIRA] Resolved: (JBLOGGING-66) Class org.jboss.logging.JDKLevel causes classloader leaks on undeployment of projects using jboss-logging in their war

[David Lloyd (JIRA)]

     [ https://issues.jboss.org/browse/JBLOGGING-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved JBLOGGING-66.
----------------------------------

    Resolution: Won't Fix


It's really more "Can't Fix" than "Won't Fix".  In the JBoss Application Server, aside from having only one instance of JBoss Logging (of course), we replace the JDK LogManager implementation and take measures to prevent the JUL Level class from recording level subclasses.  Thus even if a deployment registers its own levels (outside of any logging framework), they won't actually cause a class loader leak.  This is the responsibility of the application server environment.  I recommend that you register an issue with the Glassfish team and let them know that it is the application server's responsibility to avoid leaks like this, even when it is caused by a poor JDK design choice (perhaps especially then).

> Class org.jboss.logging.JDKLevel causes classloader leaks on undeployment of projects using jboss-logging in their war
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-66
>                 URL: https://issues.jboss.org/browse/JBLOGGING-66
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: java version "1.6.0_22"
> OpenJDK Runtime Environment (IcedTea6 1.10.2) (fedora-58.1.10.2.fc15-x86_64)
> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
> x64 Core 2 Duo laptop with 4GB RAM
>            Reporter: Craig Ringer
>            Assignee: David Lloyd
>
> I've been chasing classloader leaks that've been causing my app to fail to redeploy after a few iterations. A bit of digging using jmap and jhat has begun to strongly suggest that JBoss Logging is the problem.
> The issue is exactly the same as the one used as an example in this article on tracing classloader leaks:
>   http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java
> Specifically, org.jboss.logging.JDKLevel extends java.util.logging.Level . Unfortunately, java.util.logging.Level keeps a static array of all known logging levels. If JBoss Logging was deployed as part of an application war, that means there's a reference kept from an application server class (java.util.logging.Level) to a client application class (org.jboss.logging.JDKLevel). This keeps the whole reference chain intact and stops the application classloader from being destroyed.
> This is a problem on Glassfish 3.1, because JBoss Logging isn't included in the application server so it must be deployed by applications if they want to use things like JBoss Seam.
> It should be possible to add jboss-logging to glassfish/domains/domain1/lib to work around this, by making sure that org.jboss.logging.JDKLevel is loaded by the appserver classloader not the classloader of the deployed application.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira