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

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.

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

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