Jersey is a server side technology, not client side.
Travis
On Mon, Aug 25, 2008 at 10:40 AM, Markus KARG <markus.karg_at_gmx.net> wrote:
> Travis,
>
>> 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
>>
> First of all, I am not talking about server sided @GETs but about client
> sided WebResource.get() invocations. For the server side there is no need to
> have a cache in the application, since you can just add a SQUID box in front
> of the original server, working as a reverse cache.
>
> Besides that, my proposal will automatically use the cache behind the
> curtains. That means, no need to add any code to any @GETs. The problem with
> HTTP caching is that you must use it *everywhere* to keep your cache valid.
> For example: In ALL @PUTs / @DELETEs you must invalidate the cache. Imagine
> the lot of work that you have to invest for writing all that cache
> management; imagine the code that is splattered with cache management lines
> and will become unreadable; imagine the risk of incorrectly invalidating the
> cache at one single @PUT method and the time you need to find out where the
> fault is. Also my proposal will work with not only JAX-RS but also with ANY
> other kind of URLConnection code, i. e. the cache automatically gets shared
> between Client API and non-Client API. So it is much easier and efficient
> than writing your own code in the application. Last but not least, my
> proposal supports the idea of aspects / separation of concerns.
>
> Regards
> Markus
>
>
>>
>> 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
>>
>>
>>
>
> --
> http://www.xing.com/go/invita/58469
>
>