[jboss-jira] [JBoss JIRA] (JBLOGGING-118) Subclass of java.util.logging.Level creates PermGen memory leak

[Murmur Murmur (JIRA)]

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

Murmur Murmur edited comment on JBLOGGING-118 at 10/5/15 7:29 AM:
------------------------------------------------------------------

I don't have a luxury of installing new jars server-side. All war files should be self contained applications. Some apps use a standard JDK provided logging capability, want to minimize all extra libraries or both valid reasons. This is currently a no-go if app is using say OpenJPA+JerseyRest+validator at annotations, jboss-logging is not behaving nice with any of that combination.

Is there an internal valid reasons to have a subclass of Level even if it's known to create memory problems? If yes I understand this and won't push this change anymore. I use my own version of library and state in Stackoverflow and rest forums it is just an unofficial fix, don't expect it to pull regular upstream changes.

Another globally side-effect safe working solution, very easy to implement would be to have JDKLoggerProvider2.java+JDKLogger2.java implementation. It did not use JDKLevel.java class at all. No fragmented jboss-logging libraries in wild.


was (Author: murmur001):
I don't have a luxury of installing new jars server-side. All war files should be self contained applications. Some apps use a standard JDK provided logging capability, want to minimize all extra libraries or both valid reasons. This is currently a no-go if app is using say OpenJPA+JerseyRest+validator at annotations, jboss-logging is not behaving nice with any of that combination.

Is there an internal valid reasons to have a subclass of Level even if it's known to create memory problems? If yes I understand this and and won't push this change anymore. I use my own version of library and state in Stackoverflow and rest forums it is just an unofficial fix, don't expect it to pull regular upstream changes.

Another globally side-effect safe working solution, very easy to implement would be to have JDKLoggerProvider2.java+JDKLogger2.java implementation. It did not use JDKLevel.java class at all. No fragmented jboss-logging libraries in wild.

> Subclass of java.util.logging.Level creates PermGen memory leak
> ---------------------------------------------------------------
>
>                 Key: JBLOGGING-118
>                 URL: https://issues.jboss.org/browse/JBLOGGING-118
>             Project: JBoss Logging
>          Issue Type: Bug
>          Components: jboss-logging-jdk
>    Affects Versions: 3.3.0.Beta1
>         Environment: JDK7, Tomcat 7, OpenJPA-2.4.1, ValidationAPI-1.x, hibernate-validator-5.2.1, jboss-logging (fresh from github).
>            Reporter: Murmur Murmur
>            Assignee: James Perkins
>
> Subclass of java.util.logging.Level creates PermGen memory leak if webapp provides jboss-logging.jar inside a webapp. This happen most likely in Tomcat and hot-redeployment stops working after few times out of PermGen memory.
> It's a commonly known side effect of JDK logging library, projects should not inherit Level class. 
> See this discussion and github pull request where I have fixed this problem.
> http://stackoverflow.com/a/32412984/185565
> https://github.com/jboss-logging/jboss-logging/pull/21



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)