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

[Alessio Soldano]

Il 31/10/2016 11:41, Alessio Soldano ha scritto:
> 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.
>
> 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.
>
> Am I missing something here? Any thoughts / idea?
Note, I could modify https://github.com/jboss/jboss-jaxrs-api_spec to 
avoid the caching mechanism, but it's arguable if that change would be 
ok (the javadoc clearly says there's that caching mechanism, so users 
might expect that).

Alessio