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

[Ron Sigal]

On 11/02/2016 11:35 AM, Ron Sigal wrote:
>
> 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.

Which, of course, makes no sense because we're trying to get an 
instance. D'oh!!

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