Sure, but is that really a need to have a configurable threading model?
Again, unless we don't have that for the server I cannot see that we need
that for the client, as it is ridiculously easy to use executors within the
client application's code directly (especially with the combination of
fork-join and lambda expressions).
> -----Original Message-----
> From: Adam Bien [mailto:abien_at_adam-bien.com]
> Sent: Dienstag, 12. April 2011 22:16
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Client framework
>
> You could inject a CDI Client into an EJB / CDI managed bean. Then you
> get some concurrency. This is very common approach.
>
> I would widen my comment to "resource pooling" in general. I had
> already trouble in the past with Axis Client threading model and HTTP -
> client in particular....
> On 12.04.2011, at 21:41, Markus KARG wrote:
>
> > I do not see why pluggable executor services are needed for
> *clients*: For
> > "real" clients it is rather relaxed (how many GETs and PUTs does a
> "real"
> > client do per second that a pluggable policy is needed instead of
> just
> > letting the application do the threading *around* the client API
> calls?) and
> > for server sided clients the question is why the client API must
> support
> > this while the server API actually does not (or did I miss something?
> Where
> > in JAX-RS 1.1 can I plug in a different threading model?).
> >
> >> -----Original Message-----
> >> From: Jan Algermissen [mailto:algermissen1971_at_me.com]
> >> Sent: Dienstag, 12. April 2011 20:25
> >> To: jsr339-experts_at_jax-rs-spec.java.net
> >> Subject: [jsr339-experts] Re: Client framework
> >>
> >>
> >> On Apr 12, 2011, at 1:21 PM, Adam Bien wrote:
> >>
> >>> Regarding SPI: IMHO at least the threading model (ExecutorService)
> >> should be pluggable and so well defined.
> >>> A client API could and will be used on server side as well - so
> >> threading and scalability will be an issue.
> >>
> >> +1
> >>
> >> And this is an important issue in general and IMHO deserves the same
> >> attention as 'traditional' (aka database) connection management.
> IOW,
> >> HTTP connection management should be orthogonal to resource
> >> implementations. Several resources could well use the same HTTP
> >> connection to an upstream HTTP server.
> >>
> >> Jan
> >>
> >>
> >>>
> >>>
> >>> On 07.04.2011, at 21:10, Markus KARG wrote:
> >>>
> >>>> Actually I think for users it would be of more interest to have a
> >> high level
> >>>> API. IMHO least users in the first step will actually want to
> >> declare using
> >>>> a particular http stack, but just want to get started most easily
> >> with a
> >>>> stable solution. It's a benefit of your framework to also provide
> >> this
> >>>> pluggability, but I don't see that it must be part of the JAX-RS
> >> standard.
> >>>> You could just support it "under the hood" for example by setting
> >> system
> >>>> properties etc. What the users want from my understanding is a
> >> fluent API
> >>>> that allows them to talk to any http based REST service. What
> >> technical way
> >>>> this is done is of low interest. Proof: Nobody asked to ever add
> >> such a
> >>>> plugability into JAX-RS 1 (server side) so far. So why should one
> >> ask for
> >>>> that on the client side?
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Bill Burke [mailto:bburke_at_redhat.com]
> >>>>> Sent: Mittwoch, 6. April 2011 23:09
> >>>>> To: jsr339-experts_at_jax-rs-spec.java.net
> >>>>> Subject: [jsr339-experts] Client framework
> >>>>>
> >>>>> i'd really like to start the ball rolling on this. I guess we'll
> >> be
> >>>>> deriving from the Jersey low-level API?
> >>>>>
> >>>>> IMO, some thought on the Exception hierarchy should be mapped out
> >> here
> >>>>> as well concurrently (JAX_RS_SPEC-48). Also, in resteasy we have
> >> an
> >>>>> SPI
> >>>>> for plugging in various HTTP libraries for the client API to run
> on
> >> top
> >>>>> of (Apache HTTP Client 3.x, 4.x, java.net.URL) that maybe we
> should
> >>>>> define within JAX-RS as well.
> >>>>>
> >>>>> Finally, my users are very fond of our proxy framework [1].
> >> Basically
> >>>>> it allows you to use the exact same JAX-RS annotations on the
> >> client
> >>>>> side so that you can map method invocations into an HTTP request.
> >> In
> >>>>> most cases you can re-use the same interface on both the client
> and
> >>>>> server side.
> >>>>>
> >>>>> [1]
> >>>>>
> >>
> http://docs.jboss.org/resteasy/docs/2.0.0.GA/userguide/html/RESTEasy_Cl
> >>>>> ient_Framework.html
> >>>>> --
> >>>>> Bill Burke
> >>>>> JBoss, a division of Red Hat
> >>>>> http://bill.burkecentral.com
> >>>>
> >>>
> >>> Consultant, Author, Speaker, Java Champion
> >>>
> >>> Weblog: blog.adam-bien.com
> >>> press: press.adam-bien.com
> >>> eMail: abien_at_adam-bien.com
> >>> twitter: twitter.com/adambien
> >>> Mobile: 0049(0)170 280 3144
> >>>
> >>> Author: 7 (Java SE/EE, SOA) Books, about 100 articles
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
>