Hi,
A bit late to the discussion...
I was hoping that i could plug in any low-level grizzly client API
into the Jersey client API (just like we have done for
HttpURLConnection and The Apache HTTP client) and then use any async
capability as required, and modify the Jersey APIs as required too.
Also since services may also be clients is there any advantage to
sharing config/threading logic between the two?
Paul.
On Mar 2, 2009, at 4:10 PM, Jeanfrancois Arcand wrote:
> Salut,
>
> Oleksiy Stashok wrote:
>> Hi,
>> during our last meeting we discussed possibility of implementing
>> HTTP client, based on Grizzly.
>> Hubert expressed certain interest in starting working on the
>> implementation, but I think we can exptect other developers to
>> contribute.
>> Some time ago we started discussion on possible API, Grizzly HTTP
>> client may have, we took a look at several implementations and API
>> they propose. Last propose we had from Paul (project Jersey lead),
>> pls. see mails history bellow.
>
> And we have an issue filled:
>
> https://grizzly.dev.java.net/issues/show_bug.cgi?id=265
>
>
> Here is just code snippet , with some API proposal
>> from Paul:
>> ----------------------------------------------------------------------------------------------------------------------------
>> ... it is too request/response focused and not resource focused
>> with the uniform interface at the fore of the API with the ability
>> to easily use many Java types directly for representations.
>> Rather than this:
>> Session s = new Session();
>> Response r = s.get("http://www.java.net");
>> System.out.println(r.getBody());
>> //read an image
>> r = s.get("http://java.net/images/header_jnet_new.jpg");
>> Image img = ImageIO.read(r.getBodyAsStream());
>> You can type that actual resource and its uniform interface:
>> Client c = Client.create();
>> WebResource r = c.resource("http://www.java.net");
>> String s = r.get(String.class);
>> Image r = r.path("images/header_jnet_new.jpg").get(Image.class);
>> Or:
>> AsyncWebResource r = c.asyncResource("http://www.java.net");
>> // Non blocking, but not efficiently implemented and no callback
>> mechanism
>> Future<Image> r = r.path("images/
>> header_jnet_new.jpg").get(Image.class);
>> ------------------------------------------------------------------------------------------------------------------------
>> Here is Jersey client side API Paul references to [1].
>> IMHO this API looks quite general and could be used in Grizzly.
>> Will be glad to hear your opinions.
>
> +1 (the link is broken BTW ;-)...checked manually the code :-)). We
> can probably split the tasks amongst us. I will let peoples digest
>
> https://grizzly.dev.java.net/issues/show_bug.cgi?id=265
>
> and we should split the task amongs us and see if we can build this
> monster in different modules :-)
>
> A+
>
> -- Jeanfrancois
>
>
>
>> Thanks.
>> WBR,
>> Alexey.
>> [1] https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0/api/jersey/com/sun/jersey/api/client/package-summary.html
>> Begin forwarded message:
>>> *From: *Paul Sandoz <Paul.Sandoz_at_Sun.COM
>>> <mailto:Paul.Sandoz_at_Sun.COM>>
>>> *Date: *November 26, 2008 3:36:17 PM GMT+01:00
>>> *To: *Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM <mailto:Oleksiy.Stashok_at_Sun.COM
>>> >>
>>> *Cc: *Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM <mailto:Jeanfrancois.Arcand_at_Sun.COM
>>> >>
>>> *Subject: **Re: Jersey client side API*
>>>
>>>
>>> On Nov 26, 2008, at 3:06 PM, Oleksiy Stashok wrote:
>>>
>>>>>> wanted to ask your opinion, whether it's theoretically possible
>>>>>> to use Jersey client side API as general HTTP client side
>>>>>> implementation?
>>>>>> In other words as replacement of HttpURLConnection?
>>>>>>
>>>>>
>>>>> That was the idea. It is designed to be a high-level ease of use
>>>>> API that leverages a lower-level API that should not really be
>>>>> used by the average developer. Currently HttpURLConnection is
>>>>> used underneath but we also have a prototype Apache HTTP client
>>>>> implementation as well. The advantage of the latter is there are
>>>>> many more features available to leverage like better caching,
>>>>> cookie and auth support.
>>>> Ok.
>>>> BTW, looks like Apache HTTP client is not based on Mina!?
>>>>
>>>
>>> Not sure, but i suspect not.
>>>
>>>
>>>>
>>>>>> I know you spend some time to work with JF on Comet related
>>>>>> stuff, does it mean that Jersey client side API support async.
>>>>>> server notifications?
>>>>>>
>>>>>
>>>>> Not quite yet as i would like it. There is an AsyncWebResource:
>>>>>
>>>>> https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0/api/jersey/com/sun/jersey/api/client/AsyncWebResource.html
>>>>>
>>>>> But the implementation underneath is really dumb because there
>>>>> is no async support in HttpURLConnection (see end of email for
>>>>> the implementation).
>>>> Right. This is what we wanted to change with Grizzly.
>>>>
>>>>
>>>>>> We were asked for Grizzly based HTTP client implementation long
>>>>>> time ago... we even have a person, who could be interested to
>>>>>> do that and I'm trying to help him as much as possible.
>>>>>>
>>>>>
>>>>> OK. I would be great if we could work together on this. A clean,
>>>>> neat low-level HTTP client API with great aysnc support would be
>>>>> very useful but we also need to supply additional functionality:
>>>>> cache?, cookie, auth etc otherwise it is unlikely to get used a
>>>>> lot.
>>>>>
>>>>> Paul.
>>>>>
>>>>> private <T> Future<T> handle(final GenericType<T> gt, final
>>>>> ClientRequest ro) {
>>>>> FutureTask<T> ft = new FutureTask<T>(new Callable<T>() {
>>>>> public T call() throws Exception {
>>>>> ClientResponse r = getHeadHandler().handle(ro);
>>>>>
>>>>> if (gt.getRawClass() == ClientResponse.class)
>>>>> gt.getRawClass().cast(r);
>>>>>
>>>>> if (r.getStatus() < 300) return r.getEntity(gt);
>>>>>
>>>>> throw new UniformInterfaceException("Status: " +
>>>>> r.getStatus(), r);
>>>>> }
>>>>> });
>>>>> new Thread(ft).start();
>>>>> return ft;
>>>>> }
>>>>
>>>> Are you aware about project swingx [1].
>>>
>>> Yes, but i from high-level REST persecutive i think it is wrongly
>>> focused as is the Apache HTTP client API. It is too request/
>>> response focused and not resource focused with the uniform
>>> interface at the fore of the API with the ability to easily use
>>> many Java types directly for representations.
>>>
>>> Rather than this:
>>>
>>> Session s = new Session();
>>> Response r = s.get("http://www.java.net");
>>> System.out.println(r.getBody());
>>>
>>> //read an image
>>> r = s.get("http://java.net/images/header_jnet_new.jpg");
>>> Image img = ImageIO.read(r.getBodyAsStream());
>>>
>>> You can type that actual resource and its uniform interface:
>>>
>>> Client c = Client.create();
>>> WebResource r = c.resource("http://www.java.net");
>>>
>>> String s = r.get(String.class);
>>>
>>> Image r = r.path("images/header_jnet_new.jpg").get(Image.class);
>>>
>>> Or:
>>>
>>> AsyncWebResource r = c.asyncResource("http://www.java.net");
>>> // Non blocking, but not efficiently implemented and no callback
>>> mechanism
>>> Future<Image> r = r.path("images/
>>> header_jnet_new.jpg").get(Image.class);
>>>
>>>
>>> Once you type a resource it makes it easy to pass around, for
>>> example we could support injection of WebResource instances
>>> configured appropriately on server-side resource classes. The
>>> ideal underlying scenario for Glassfish is that when a server is
>>> also a client threads are efficiently used in either case for sync/
>>> async. I think it will be increasingly the case that servers will
>>> become clients if the RESTful approach starts gaining more
>>> traction in the enterprise since service composition becomes a lot
>>> easier to scale, support and manage.
>>>
>>> Paul.
>>>
>>>> They also have some HTTP client API, which looks quite nice [2],
>>>> though they don't use NIO and non-blocking either.
>>>>
>>>
>>>> Thanks.
>>>>
>>>> WBR,
>>>> Alexey.
>>>>
>>>> [1] https://swingx-ws.dev.java.net/source/browse/swingx-ws/src/java/org/jdesktop/http/
>>>> [2] http://today.java.net/pub/a/today/2006/10/11/web-swinging.html
>>>>>
>>>>>
>>>>
>>>
