I just do not see the benefit of that. What is the benefit for the user of
providing an execution service to the client API instead of just directly
using the execution service?
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Mittwoch, 13. April 2011 00:23
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Client framework
>
> I still don't understand why you are against this. We would have to
> have something like a Request factory anyways like we already do for
> RuntimeDelegate.
>
> On 4/12/11 3:49 PM, Markus KARG wrote:
> > 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
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com