Markus,
Why not just use Ehcache where you want it? ie: on your @GET's for example,
do the standard issue:
1. Look for object in cache
2. If exists, return it
3. If not, get it from database, stick it in the cache, then return it
Travis
On Mon, Aug 25, 2008 at 10:07 AM, Markus KARG <markus.karg_at_gmx.net> wrote:
>
> The JRE comes with a default framework for application-local Cache: You
>>> can write your own cache provider and configure the JRE to use it. Nice. So
>>> when using the Jersey Client API:
>>>
>>> (a) Will it come with a default implementation of an application-local
>>> Cache?
>>>
>>> (b) Will there at least be support for the above-mentioned framework?
>>>
>> Can you provide more information/links to the "application-local Cache" as
>> i do not know what it is. If this cache plugs in to HttpURLConnection you
>> may be able to use it as the Client API uses HttpURLConnection underneath.
>>
> With "application-local Cache" I mean a HTTP/1.1 compliant cache that is
> located inside of the client application itself. The most known instance of
> this is the browser cache. But certainly in our case, we do not talk about a
> browser, because we do JAX-RS but not JSF, so our front ent is not a browser
> but a Java application.
>
> The JRE comes with a default interface to attach such "application-level
> Cache": java.net.ResponseCache. Unfortunately there is no default
> implementation provided in the JRE, and writing a HTTP/1.1 compliant cache
> is not as easy as one might think. So possibly in your brilliant Client API
> there might be such an implementation already, who knows? :-)
>
> I have asked Greg Luck, the author of EHCACHE (a HTTP/1.1 compliant cache
> written in pure Java) whether he want to provide an adapter from
> java.net.ResponseCache to EHCACHE and he said that he is willing to do. So
> maybe it is interesting for the Jersey team to contact him and to
> incorporate that work into the Jersey Client API? It will be very
> beneficial!
>
>> Currently I have installed SQUID on my laptop to "simulate"
>>> application-local cache, but certainly that is a bit like breaking a fly on
>>> a wheel.
>>>
>> Yes.
>>
>> It is possible to write a cache using the Client filter API, either
>> application specific like caching JAXB objects in memory (so they do not
>> need to be repeatedly unmarshalled) or say plug in a general in-memory
>> cache, perhaps using say Ehcache.
>>
> Regarding EHCACHE: See above. Would be great if the Client API -- including
> such a local cache -- would be part of JAX-RS 2.0 :-)
>
>> If you need such functionality can you log an issue so we can
>> track/prioritize.
>>
> Done: https://jersey.dev.java.net/issues/show_bug.cgi?id=100 :-)
>
> Have Fun
>
> Markus
>
> --
> http://www.xing.com/go/invita/58469
>
>