[jboss-jira] [JBoss JIRA] (AS7-3735) javax.ws.rs.ext.FactoryFinder use application's Class Loader which causes CL Memory Leak

[Philippe Guinot (JIRA)]

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

Philippe Guinot commented on AS7-3735:
--------------------------------------

Yeah, that's it. Resteasy is deployed within EarContent/lib.

Maybe we should only use Resteasy as a Module, but I was actually running with a different memory leak issue in that case (cf. https://issues.jboss.org/browse/RESTEASY-660 - but seems to actually be a Seam 2 issue)
                
> javax.ws.rs.ext.FactoryFinder use application's Class Loader which causes CL Memory Leak
> ----------------------------------------------------------------------------------------
>
>                 Key: AS7-3735
>                 URL: https://issues.jboss.org/browse/AS7-3735
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.1.0.CR1b
>         Environment: Seam 2.2.2 webapp with Resteasy 2.3.1
>            Reporter: Philippe Guinot
>            Assignee: David Lloyd
>              Labels: CacheControl, Cookie, EntityTag, FactoryFinder, MediaType, NewCookie, RuntimeDelegate, classloader, javax.ws.rs.api, leak, resteasy
>
> Deploying a Seam 2 application with Resteasy (deployed as JAR withing EarContent/lib) actually causes the following issue:
> * When Seam access classes such as CacheControl, Cookie, EntityTag, MediaType or NewCookie, it loads my application's Resteasy classes, as using the CurrentThread's context class loader.
> * So I ended up with the static field delegate of those classes keeping a reference to my application's class loader which cause a CL Memory Leak.
> Since, the javax.ws.rs.core.Cookie/Entitytag, etc.. are server side components, I don't think they should refer to any deployed application.
> To avoid this, the only way to do so, was at the server start-up to initialize those components in that way:
> {code}
> try {
>     javax.ws.rs.core.CacheControl.valueOf("");
> } catch (IllegalArgumentException e) {
> }
> try {
>     javax.ws.rs.core.Cookie.valueOf("");
> } catch (IllegalArgumentException e) {
> }
> try {
>     javax.ws.rs.core.EntityTag.valueOf("");
> } catch (IllegalArgumentException e) {
> }
> try {
>     javax.ws.rs.core.MediaType.valueOf("");
> } catch (IllegalArgumentException e) {
> }
> try {
>     javax.ws.rs.core.NewCookie.valueOf("");
> } catch (IllegalArgumentException e) {
> }{code}
> (I put this in org.jboss.as.server.Main before line 91, but this is not the best place of course. Perhaps a class such as JreMemoryLeakPreventionListener should be used, but for the moment the use of this listener is disabled in JBoss Web 7, see https://community.jboss.org/thread/164760 )
> But, since the RuntimeDelegate needed to find the Resteasy classed, I had to use the module ClassLoader instead of the current context class loader in the javax.ws.rs.ext.FactoryFinder.getContextClassLoader() method. Then, as the javax.ws.rs.api module actually depends on the org.jboss.resteasy.resteasy-jaxrs, this works well and avoids any dependency to my application's class loader.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira