I understand, but see, for an application programmer it is already rather
easy to set up an executor and submit jobs to it calling the client API
themselves. So what benefit would it have to instead provide the executor to
the client API and let the client internally submit the jobs? I say that
because "external" use of executors will become even simpler once Closures
are there in JDK8. So what is the benefit that the application programmer
will gain?
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Dienstag, 12. April 2011 21:46
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Client framework
>
> Well, the pluggability could be as simple as I outlined in my previous
> email. Or the "Executor" could just be a factory for Request objects
> (and I hope Proxy objects too). Apache HTTP Client works via the
> executor model, so I don't understand what your beef is.
>
> On 4/12/11 3:41 PM, 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com