RESTEasy OAuth2
by Alessio Soldano
Folks,
Jim is currently looking at Elytron integration in RESTEasy and he has
just brought to my attention an interesting topic. The RESTEasy Oauth2
integration was initially meant for AS 7 and not updated afterwards. It
also (partially) overlaps with KeyCloak these days.
So I'm wondering what we really want to do with it; it might make sense
to deprecate (part of) it and properly integration KeyCloak instead
(documenting, etc.). Any thought?
Cheers
Alessio
9 years
ResteasyProviderFactory and the JAX-RS api RuntimeDelegate cache
by Alessio Soldano
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
9 years, 1 month
