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

[Alessio Soldano]

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