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

[Ron Sigal]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/resteasy-dev

-- 
My company's smarter than your company (unless you work for Red Hat)