[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=12618006#comment-12618006 ] 

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

Thanks for looking into it. I'll chase it up with the Glassfish folks and see if they can apply a similar override to fix the JDK logging issues as they're exposed there. As it happens I've moved to JBoss AS 7 in the mean time, and I'm rather happy to see it all works smoothly there.

This is one of the times I really wish for a backward-incompatible Java release to fix all the horrid messy little corners of the API. Get rid of old-style enumerations, unify logging, drop Java EE 2, generify all classes, etc. Alas, I fear it'll never happen.

Thanks again.


> 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