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

[Jason Greene (JIRA)]

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

Jason Greene commented on AS7-3735:
-----------------------------------

The main problem, as you observed, is with the JAX-RS api. It's designed to support a pluggable (replaceable) implementation (uses TCCL and scans for META-INF/services much like JAXP, but the problem is that it caches the results in a static variable which contradicts plug-ability. We need to investigate what it would take to fix it (although it will have to wait until after 7.1.0).

There is another issue though. If the app server detects usage of JAX-RS in your deployment it adds dependencies on resteasy (and the JAX-RS api) which are intended to be in such an order that it would override your usage. Ear/lib is, however, taking precedence, which it shouldn't be. So that's the second problem.

99% of the time you don't want to override the JAX-RS impl we provide because you will disable integration with other EE capabilities.  However if you do want to provide your own, the solution at the moment would be to add an exclusion to your deployment to filter out inclusion of "javax.ws.rs.api" and all of the resteasy modules. If you do provide your own you will have to do things like declare the resteasy servlet in web.xml, which are normally automated.
                
> 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