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
> >
> >
> >
> >
> >
> >
> >
> >