Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-894

javax.ws.rs.ext.FactoryFinder use application's Class Loader which causes CL Memory Leak

    Details

      Description

      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:

      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) {
       
      }

      (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.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                swd847 Stuart Douglas
                Reporter:
                guinotphil Philippe Guinot
              • Votes:
                0 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: