Hi, while working on the changes for https://issues.jboss.org/browse/RESTEASY-1531 , I figured out that we possibly have a general issue with the javax.ws.rs.ext.RuntimeDelegate cache mechanism. That class basically has a static cachedDelegate which is used to store the first resolved implementation of RuntimeDelegate and offer it to any following request. The problem is that RESTEasy implementation of RuntimeDegate, ResteasyProviderFactory, comes with many data (look at its field members) that relates to a specific application / deployment. Sharing an instance among different application does not seem correct. The ResteasyDeployment class is also setting and clearing that cache value using ResteasyProviderFactory:setInstance and ResteasyProviderFactory: clearInstanceIfEqual methods which I believe results in a mess in-container, with multiple deployments going over others (the clear method is called upon undeployment). The problem seems to be mitigated by the fact that many users simply go and create a new ResteasyProviderFactory using our proprietary api, instead of getting it through standard JAX-RS api. To deal with a similar problem in my branch for RESTEASY-1531 I've basically duplicated the resolution mechanism within RESTEasy and bypassed the cache stuff, but the problem is still there for pure JAX-RS api users. Am I missing something here? Any thoughts / idea?

On 10/31/2016 06:41 AM, Alessio Soldano wrote: > Hi, > > while working on the changes for > https://issues.jboss.org/browse/RESTEASY-1531 , I figured out that we > possibly have a general issue with the javax.ws.rs.ext.RuntimeDelegate > cache mechanism. That class basically has a static cachedDelegate which > is used to store the first resolved implementation of RuntimeDelegate > and offer it to any following request. > > The problem is that RESTEasy implementation of RuntimeDegate, > ResteasyProviderFactory, comes with many data (look at its field > members) that relates to a specific application / deployment. Sharing an > instance among different application does not seem correct. > > The ResteasyDeployment class is also setting and clearing that cache > value using ResteasyProviderFactory:setInstance and > ResteasyProviderFactory: clearInstanceIfEqual methods which I believe > results in a mess in-container, with multiple deployments going over > others (the clear method is called upon undeployment). > > The problem seems to be mitigated by the fact that many users simply go > and create a new ResteasyProviderFactory using our proprietary api, > instead of getting it through standard JAX-RS api. I see that the RuntimeDelegate javadoc says, "Regular users of JAX-RS are not expected to use this class directly". Doesn't that protect Resteasy?

Of course, maybe JAX-RS should change RuntimeDelegate. For example, getInstance() could be made abstract.

> To deal with a similar problem in my branch for RESTEASY-1531 I've > basically duplicated the resolution mechanism within RESTEasy and > bypassed the cache stuff, but the problem is still there for pure JAX-RS > api users.

On 11/02/2016 07:15 AM, Alessio Soldano wrote: > Il 02/11/2016 02:49, Ron Sigal ha scritto: >> On 10/31/2016 06:41 AM, Alessio Soldano wrote: >>> Hi, >>> >>> while working on the changes for >>> https://issues.jboss.org/browse/RESTEASY-1531 , I figured out that we >>> possibly have a general issue with the javax.ws.rs.ext.RuntimeDelegate >>> cache mechanism. That class basically has a static cachedDelegate which >>> is used to store the first resolved implementation of RuntimeDelegate >>> and offer it to any following request. >>> >>> The problem is that RESTEasy implementation of RuntimeDegate, >>> ResteasyProviderFactory, comes with many data (look at its field >>> members) that relates to a specific application / deployment. Sharing an >>> instance among different application does not seem correct. >>> >>> The ResteasyDeployment class is also setting and clearing that cache >>> value using ResteasyProviderFactory:setInstance and >>> ResteasyProviderFactory: clearInstanceIfEqual methods which I believe >>> results in a mess in-container, with multiple deployments going over >>> others (the clear method is called upon undeployment). >>> >>> The problem seems to be mitigated by the fact that many users simply go >>> and create a new ResteasyProviderFactory using our proprietary api, >>> instead of getting it through standard JAX-RS api. >> I see that the RuntimeDelegate javadoc says, "Regular users of JAX-RS >> are not expected to use this class directly". Doesn't that protect >> Resteasy? > Well, possibly yes :-) It offers us an argument for telling users not to > use RuntimeDelegate directly and make the integration work internally > the way we need/want (see below). > > In general, though, at a given point in the future we should really try > spending some time to write down a list of the classes that are really > meant for final user consumption and which should really be in public > modules, the rest having to go into private modules. +1 >> Of course, maybe JAX-RS should change RuntimeDelegate. For >> example, getInstance() could be made abstract. > mmh, getInstance() is a static method, so having it abstract won't help, > I think. Yes, I was thinking it could be turned into an abstract non-static method. I should have been more specific.

>>> To deal with a similar problem in my branch for RESTEASY-1531 I've >>> basically duplicated the resolution mechanism within RESTEasy and >>> bypassed the cache stuff, but the problem is still there for pure JAX-RS >>> api users. > So, I think we need to keep this "workaround". > > Cheers > Alessio > _______________________________________________ > resteasy-dev mailing list > resteasy-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/resteasy-dev