I agree that caching is the job of the client side container, but JAX RS
Client API is part of it, so the question is: Which working group is
effectively in charge of providing that? From the view of a JAX RS user, it
is JAX RS, since I do not care whether JAX RS is providing it or using a
deeper layer (just as I do not care about how http coonnection management is
done). The JAX RS providers say, it is NOT their part but it is part of the
transport. Ok, but who is providing the http transport in a Java EE
environment, and who in a Java SE environment?
> -----Original Message-----
> From: Santiago Pericas-Geertsen
> [mailto:Santiago.PericasGeertsen_at_oracle.com]
> Sent: Freitag, 20. Mai 2011 16:15
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Client-Side Components
>
> Jan,
>
> I fully agree with your assessment. I think ease of use and
> infrastructure support has improved significantly in EE over the last
> few years, and many of these features are sorely missed while
> programming clients. Personally, I'd like to have managed beans, DI,
> IoC, HTTP connection management, thread management, caching, among
> others. I.e., some sort of lightweight container.
>
> HTML5 browsers are, in fact, that (maybe not that lightweight because
> of UI rendering, etc.). They provide many of these services but for
> Javascript applications. The idea of client-side containers for Java
> still sounds a bit wacky to me, but not us much as it did some time
> ago.
>
> -- Santiago
>
> On May 20, 2011, at 4:32 AM, algermissen1971 wrote:
>
> > Apologies - I do not want to re-open this thread, but I think the
> problem regarding caching actually has its cause at a layer below.
> >
> > On the server side, JAX-RS (and Jersey) relies on essential pieces
> of the system to be provided by the underlying container (Java EE
> implementation), one example being the HTTP server connector. JAX-RS
> does not need to address these aspects but instead can rely on high-
> quality implementations to simply 'be there'.
> >
> > On the client side, two of these aspects are the client connector and
> the private cache - both essential aspects of HTTP client-side
> software. Unfortunately, the client side does not share the same luxury
> of sitting on top of high quality frameworks that simply provide
> implementations of client connector and cache out-of-the-box.
> >
> > In the case of the client connector Jersey comes with its own
> implementation, but for any serious use, you have to make use of the
> connector implementation ApacheHttpClient. Forcing you to add in an
> extra ('proprietary' if you want) library with associated extra
> configuration.
> >
> > Caching looks like being the same problem: There is no underlying
> container that simply provides a cache ([1]) and hence you have to put
> one in yourself.
> >
> > To me it looks as if an equivalent to Java EE is missing for client
> application. Some piece of software that deals with HTTP connection
> management (which is clearly beyond the scope of JAX-RS) and client
> side caching (then also beyond the scope of JAX-RS)
> >
> > Bottom line: I am developing some HTTP client side code, I'd really
> prefer to just have some core-package provide me with HTTP client
> connections and have it deal with the caching of the traffic that runs
> through them. In the same way, I prefer to have the Java EE container
> deal with database connection management.
> >
> > Makes sense?
> >
> >
> > Jan
> >
> >
> > [1] Interestingly I just learned the other day that Windows comes
> with a cache that you can simply enable for .Net HTTP clients using a
> single flag. So in this case, the cache is not provided by a framework,
> but by the OS directly. Not bad - but luxury of the closed MS world.
> >
> >