users@jersey.java.net

[Jersey] Re: Feedback on non-blocking client

From: Stephane Bailliez <sbailliez_at_gmail.com>
Date: Fri, 12 Oct 2012 10:11:26 -0400

On Fri, Oct 12, 2012 at 6:37 AM, Marek Potociar
<marek.potociar_at_oracle.com>wrote:

>
> Please check the 2.0 impl here if you want:
> https://github.com/jersey/jersey
> You may be interested in core-client and connectors/grizzly-connector
> modules. As usual, we would appreciate your feedback.
>

Thanks ! wil try to check it out asap.


> Other scenario is that we may want to substitute grizzly2 by netty
> provider.
>
>
> If I'm correct, there is some refactoring work being done in the Ning
> client that should make it easier in the future (sometime soon). We'll then
> need to update our Ning client connector integration code to be more
> generic to accept any Ning transport provider. Btw., just curious - why do
> you want to replace Grizzly with Netty? Let us know and I'll make sure to
> forward your feedback to Grizzly guys so that thay know where they need to
> improve.
>

There is not a specific technical reason (at least as of now) to do that
between netty/grizzly, but generally I try to set an environment with
libraries that are as homogeneous as possible.

it takes a very long time to be familiar with a library codebase, its
behavior in a variety of situations and the related tuning of it, so for
example it would make sense to be able to stick to one single http lib
rather than a service ending up using grizzly in one case, apache http
client 4 in another, netty, commons http client or the jdk url... or at
least trying to minimize it as much as possible.

It can be hard to avoid that diversity of clients, but definitely offer
some benefits, there are for example a lot of libraries that provides
integrates only with commons http client while cxf has only a http
transport based on the jdk url, so if you're using jersey client, you may
be in a situation quickly where interacting to 3 services over http require
you 3 different http libs... when in addition you already have some
extensions that provide filtering or instrumentation for monitoring
purposes, it can be helpful to not have to do 3 different implementations.

-- stephane