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