On 23 May, 2011,at 12:10 PM, algermissen1971 <algermissen1971_at_me.com> wrote:
>
>
>
>
> Regarding JAX-RS 2.0 what would be neccessary is an HTTP client connector class abstraction that is defined outside of JAX-RS (for example being part of Java SE).
>
> JAX-RS could build on top of that and steer clear of all issues around connection management and caching.
>
> Question is, what the ideal place for both would be
For example, how big would be the hurdle to add HTTP client connectors as a first class citizen to Java SE in a new package
javax.http
?
Jan
> and whether it would be doable to add both there (sorry, I am lacking the Java politics background understanding on this).
>
> Jan
>
>
>
>>
>>
>> -- 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.
>> >
>> >
>>