Hi Markus,
I agree that utilizing Ehcache on the client side as a HTTP/1.1
compliant cache is worth pursuing.
In relation to Travis's point about the server-side, i also think
technologies like Ehcache are interesting, especially to avoid DB
queries or say to help with fast look up of etag last-modified data
(e.g. like memcached), so there may be something that could also be
done with Jersey/Ehcache for conditional GET/PUT/DELETE.
Paul.
On Aug 25, 2008, at 7:07 PM, Markus KARG 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
>