what I would like to see in a HTTP client, is to be able to use it in web
testcase. Like simulating a http post on a server.
multi-part posting too. I read the conversation is look like all the
examples are for the reading part.
2009/3/2 Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com>
> 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
>
>
