In case you didn't see the forum thread and could help with the below issues. https://community.jboss.org/message/716191 is a forum thread about classloader leaks. Text from the forum thread: " Application ClassLoader leaks: HibernateAnnotationScanner keeps references to application’s ClassLoader (minor issue): https://issues.jboss.org/browse/AS7-3734 javax.ws.rs.ext.FactoryFinder use application’s Class Loader which causes CL Memory Leak: https://issues.jboss.org/browse/AS7-3735 javax.el.BeanELResolver.properties keeps references to undeployed classes: https://issues.jboss.org/browse/AS7-3736 Threads ContextClassLoader leaks: AWT AppContext / EventQueue ClassLoader Memory Leaks: https://issues.jboss.org/browse/AS7-3733 sun.net.www.http.KeepAliveCache preventing classloader from being garbage collected: https://issues.jboss.org/browse/AS7-3732 Threads ContextClassLoader leak caused by EJB passivation pool: https://issues.jboss.org/browse/AS7-3737 ThreadLocal pseudo-leaks: org.jboss.resteasy.util.ThreadLocalStack creates ThreadLocal pseudo-leak on AS 7: https://issues.jboss.org/browse/RESTEASY-660 " I have a fix for the JPA leak but not sure about the others. The ejb passivation pool leak probably needs the TCCL to be cleared when new threads are created for the GroupAwareBackingCacheImpl. Scott _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

org.jboss.resteasy.util.ThreadLocalStack creates ThreadLocal pseudo-leak on AS 7: https://issues.jboss.org/browse/RESTEASY-660 "

https://community.jboss.org/message/716191 is an AS7 user forum thread about application classloader leaks in a few different areas. All of them involve a Seam 2.2.2 application using Resteasy 2.3.1. One of the leaks is described in jira RESTEASY-660. Is there something that the users application has to do, to get Seam 2.2.2 to call ResteasyProviderFactory.clearContextData() at the end of a request? Scott -------- Original Message -------- Subject: Re: [jboss-as7-dev] help needed with responding to reported classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation, other)... Date: Tue, 14 Feb 2012 07:33:29 -0500 From: Bill Burke <bburke(a)redhat.com&gt; To: jboss-as7-dev(a)lists.jboss.org On 2/13/12 12:59 PM, Scott Marlow wrote: > org.jboss.resteasy.util.ThreadLocalStack creates ThreadLocal pseudo-leak > on AS 7: https://issues.jboss.org/browse/RESTEASY-660 > " > This may be Seam related. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

I agree that if the user doesn't bundle their own rest east jars, that would probably work around the issue. I haven't seen any standalone tests that recreate the leak yet but it looks likely that the application copy of ResteasyBootstrap.java (http://anonsvn.jboss.org/repos/seam/branches/community/Seam_2_2/src/reste...) would call the API ResteasyProviderFactory.setInstance(ResteasyProviderFactory factory) which would save the static reference that doesn't get cleared. Worse than that, I think the setInstance call would blow away any other ResteasyProviderFactory instance that is already set. Which backs up the assertion that rest easy jars shouldn't be bundled with a user app currently. ResteasyBootstrap should probably clear the instance at shutdown time but that wouldn't change the API static issue. On 02/14/2012 03:06 PM, Stuart Douglas wrote: > > I'm pretty sure this is because the user is bundling their own rest easy jars in EAR/lib. The API caches stuff in statics, which is keeping a reference to the user deployed RESTeasy. > > Stuart > > On 15/02/2012, at 2:17 AM, Scott Marlow wrote: > >> https://community.jboss.org/message/716191 is an AS7 user forum thread >> about application classloader leaks in a few different areas. >> >> All of them involve a Seam 2.2.2 application using Resteasy 2.3.1. One >> of the leaks is described in jira RESTEASY-660. >> >> Is there something that the users application has to do, to get Seam >> 2.2.2 to call ResteasyProviderFactory.clearContextData() at the end of a >> request? >> >> Scott >> -------- Original Message -------- >> Subject: Re: [jboss-as7-dev] help needed with responding to reported >> classloader leaks in (Rest, Rest WS, JPA, EJB3 activation/passivation, >> other)... >> Date: Tue, 14 Feb 2012 07:33:29 -0500 >> From: Bill Burke&lt;bburke(a)redhat.com&gt; >> To: jboss-as7-dev(a)lists.jboss.org >> >> >> >> On 2/13/12 12:59 PM, Scott Marlow wrote: >>> org.jboss.resteasy.util.ThreadLocalStack creates ThreadLocal pseudo-leak >>> on AS 7: https://issues.jboss.org/browse/RESTEASY-660 >>> " >>> >> >> This may be Seam related. >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> _______________________________________________ >> seam-dev mailing list >> seam-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev > _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev

On 2/13/12 12:59 PM, Scott Marlow wrote: > javax.ws.rs.ext.FactoryFinder use application’s Class Loader which > causes CL Memory Leak: https://issues.jboss.org/browse/AS7-3735 > Are the JAX-RS API jars from resteasy being used?

Bill