I could use some feedback on how to implement the OAuth2Cache interface in
the OAuth2 consumer implementation. Doug and I are following the approach
outlined earlier where our OAuth2Cache is essentially a no-op implementation
of OAuth2Cache where all methods do nothing, with the exception of the
Thanks. I've come to the same conclusion. That OAuth2Accessor needs to be
persisted. When I stubbed out a NoOp OAuth2Cache the redirect_uri servlet
request failed because it's trying to map a 'state' variable back to
accessor. Ah, I keep finding fun stuff to implement.
doug
Doug,
Both in-memory and non-caching options could be acceptable. You could even
provide your own OAuth2Store implementation that doesn't even use the
OAuth2Persistence and OAuth2Cache interfaces. It's not really possible to
make a recommendation without knowing all the variabl
A Noop cache impl should be easy to implement and is a common idiom.
On Tue, Dec 13, 2011 at 7:30 AM, daviesd wrote:
> I understand that OAuth2Cache provides a mechanism for implementing a cache
> that the OAuth2Store uses to limit requests to the OAuth2Persister.
> Howev
I understand that OAuth2Cache provides a mechanism for implementing a cache
that the OAuth2Store uses to limit requests to the OAuth2Persister.
However, if my OAuth2Persister implementation uses JPA or some other
persistence model that already has caching built-in, the OAuth2Cache is
redundant and
