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

Alessio Soldano asoldano at redhat.com
Mon Oct 31 06:41:35 EDT 2016


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?

Cheers

Alessio



More information about the resteasy-dev mailing list