Hi,
>
> A bit late to the discussion...
No, it's ok :)
> 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.
It's exactly what we're planning to do in terms of Grizzly and HTTP
client.
> Also since services may also be clients is there any advantage to
> sharing config/threading logic between the two?
I think yes, it could be just overhead for Grizzly to create own
threading/config infrastructure separately for clients.
WBR,
Alexey.
>
>
> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
