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.
>
>