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

[Craig Ringer (JIRA)]

    [ https://issues.jboss.org/browse/JBLOGGING-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611080#comment-12611080 ] 

Craig Ringer commented on JBLOGGING-66:
---------------------------------------

BTW, I encountered this issue without knowingly using JBoss Logging at all. org/jboss/logging/JDKLogger.class is bundled in Seam Solder 3.0.0.Final inside seam-solder-3.0.0.Final.jar and seam-solder-api-3.0.0.Final.jar. This makes it harder to separate out and include in the app server - I have to drop the entirety of Seam Solder into lib/ .

That's rather undesirable because Solder will activate servlet filters on all deployed apps, not just the ones that use Solder.

> 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