Re: [resteasy-dev] ResteasyProviderFactory and the JAX-RS api RuntimeDelegate cache

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