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