]
Philippe Guinot commented on AS7-3735:
--------------------------------------
With JBoss 7.1.1 I tried to add calls to
{code}
javax.ws.rs.core.CacheControl
javax.ws.rs.core.Cookie
javax.ws.rs.core.EntityTag
javax.ws.rs.core.MediaType
javax.ws.rs.core.NewCookie
{code}
in the init phase of a LifecycleListener defined in my war's jboss-web.xml. In this
phase the current class loader in not my application's CL by the jboss web
module's cl.
However, my seam EJB must be deployed before my web-app, therefore Seams calls
org.jboss.seam.resteasy.ResteasyBootstrap.init() before the init phase of the listener. At
that point the current class loader is my application's seam jar's cl...
It sounds there is no way within the application to work around this 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: REST
Affects Versions: 7.1.0.CR1b
Environment: Seam 2.2.2 webapp with Resteasy 2.3.1
Reporter: Philippe Guinot
Assignee: Stuart Douglas
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: