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