Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
Great, thanks for the input Bill.
On 29 October 2014 13:20, Bill Burke wrote:
> By default, Resteasy only allows one connection per Client. You have to
> use ResteadyClient(Builder) to expand this. Other than that, it should
> be threadsafe.
>
> Personally, I'd create the Client as an application-scoped CDI bean and
> inject it, or create one with SPring and inject it, or create one in a
> servlet listener and add it to ServletContext. If you create per
> request, then you lose any socket connection pooling that Apache Http
> Client does.
>
> On 10/27/2014 8:21 PM, Savvas Andreas Moysidis wrote:
> > The question, I suppose, is whether Client implementations are
> > thread-safe or not which is something that is not stipulated by the
> > interface contract.
> >
> > If they are(something which is sort of implied by the javadoc), then you
> > could maybe declare and use a single instance like the following? (in a
> > JavaEE context)
> >
> > @Singleton
> > public class SomeService {
> >
> > private Client restClient;
> >
> > @PostConstruct
> > private void init() {
> > restClient = ClientBuilder.newClient();
> > }
> >
> .
> > // Use restClient object here
> >
> .
> >
> > @PreDestroy
> > private void cleanUp() {
> > restClient.close();
> > }
> > }
> >
> > On 27 October 2014 23:24, Mario Diana > > wrote:
> >
> > I'd be interested in hearing what common practice is regarding
> > pooled Client objects, too. Do people use the Apache objects pool
> > library? That's the only option I've heard of. Are there other
> > mainstream solutions?
> >
> > Mario
> >
> > > On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa
> > mailto:rodrigo.uc...@gmail.com>> wrote:
> > >
> > > [...]
> >
> > > How should we implement a pool of Client objects in this scenario?
> Is there a common solution?
> > >
> > > Regards,
> > > Rodrigo Uchoa.
> >
> >
> >
>
> --
> > ___
> > Resteasy-users mailing list
> > Resteasy-users@lists.sourceforge.net
> >
> > https://lists.sourceforge.net/lists/listinfo/resteasy-users
> >
> >
> >
> >
> >
> --
> >
> >
> >
> > ___
> > Resteasy-users mailing list
> > Resteasy-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/resteasy-users
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> --
> ___
> Resteasy-users mailing list
> Resteasy-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
By default, Resteasy only allows one connection per Client. You have to
use ResteadyClient(Builder) to expand this. Other than that, it should
be threadsafe.
Personally, I'd create the Client as an application-scoped CDI bean and
inject it, or create one with SPring and inject it, or create one in a
servlet listener and add it to ServletContext. If you create per
request, then you lose any socket connection pooling that Apache Http
Client does.
On 10/27/2014 8:21 PM, Savvas Andreas Moysidis wrote:
> The question, I suppose, is whether Client implementations are
> thread-safe or not which is something that is not stipulated by the
> interface contract.
>
> If they are(something which is sort of implied by the javadoc), then you
> could maybe declare and use a single instance like the following? (in a
> JavaEE context)
>
> @Singleton
> public class SomeService {
>
> private Client restClient;
>
> @PostConstruct
> private void init() {
> restClient = ClientBuilder.newClient();
> }
> .
> // Use restClient object here
> .
>
> @PreDestroy
> private void cleanUp() {
> restClient.close();
> }
> }
>
> On 27 October 2014 23:24, Mario Diana > wrote:
>
> I'd be interested in hearing what common practice is regarding
> pooled Client objects, too. Do people use the Apache objects pool
> library? That's the only option I've heard of. Are there other
> mainstream solutions?
>
> Mario
>
> > On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa
> mailto:rodrigo.uc...@gmail.com>> wrote:
> >
> > [...]
>
> > How should we implement a pool of Client objects in this scenario? Is
> there a common solution?
> >
> > Regards,
> > Rodrigo Uchoa.
>
>
>
> --
> ___
> Resteasy-users mailing list
> Resteasy-users@lists.sourceforge.net
>
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
>
>
> --
>
>
>
> ___
> Resteasy-users mailing list
> Resteasy-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
I have also been talking with people from the Jersey team. The conclusion
seem to be the same: There's a gap in the spec, it does not clearly states
wether Client implementations should be thread-safe or not.
However both RestEasy and Jersey have done it in a thread-safe manner.
Final conclusion: No need for pooling. A singleton should do it.
On Tue, Oct 28, 2014 at 9:37 PM, Savvas Andreas Moysidis <
savvas.andreas.moysi...@gmail.com> wrote:
>
> right...took a quick look at the jsr spec (
> http://download.oracle.com/otn-pub/jcp/jaxrs-2_0-fr-eval-spec/jsr339-jaxrs-2.0-final-spec.pdf)
> but nothing seems to be mentioned about thread-safety in client-api
> implementations...so, this seems to largely be an implementation property
> rather than a spec requirement..
>
> anyway, I dug through the implementation I am using (
> *org.glassfish.jersey.client.JerseyClient*) and from what I can see the
> method for generating *WebRequest*s at least seems to be perfectly
> thread-safe:
>
> @Override
> public JerseyWebTarget target(String uri) {
> checkNotClosed();
> checkNotNull(uri, LocalizationMessages.CLIENT_URI_TEMPLATE_NULL());
> return new JerseyWebTarget(uri, this);
> }
>
> (note: checkNotNull is some preconditions-checking library statically
> imported and LocalizationMessages.CLIENT_URI_TEMPLATE_NULL() is an actual
> method call using a bizarre naming convention I've never come across
> before... )
>
> with checkNotClosed() having an implementation of:
> void checkNotClosed() {
> checkState(!closedFlag.get(),
> LocalizationMessages.CLIENT_INSTANCE_CLOSED());
> }
>
> and with the class variable closedFlag declared as:
> private final AtomicBoolean closedFlag = new AtomicBoolean(false);
>
> which of course is thread-safe.
>
> So, using a single instance and invoking only the various flavours of the
> target() method seems to be safe. Wouldn't be so sure about the various
> provider registration methods though...
>
> Savvas
>
> On 28 October 2014 12:40, Rodrigo Uchôa wrote:
>
>> Savvas,
>>
>> I have no evidence whatsoever. :)
>>
>> But it seems strange to me that if implementations should be thread-safe,
>> this information is not written in bold in the javadocs :) Or it could be
>> decision left up to vendors to decide.
>>
>> Anyway, if it is indeed thread-safe it makes things a lot easier since a
>> single instance can be used throughout the app.
>>
>> On Tue, Oct 28, 2014 at 7:50 AM, Savvas Andreas Moysidis <
>> savvas.andreas.moysi...@gmail.com> wrote:
>>
>>> Hi Rodrigo,
>>>
>>> That's precisely what my example above showcases. :)
>>>
>>> It may well be the case that the Client class is not thread-safe indeed
>>> but can I ask though what evidence have you got to believe that?
>>>
>>> Perhaps taking a look at the source code would clarify things? (or a
>>> commiter following this thread could verify instead)
>>>
>>> On 28 October 2014 01:23, Rodrigo Uchôa wrote:
>>>
if Client implementations are thread-safe, shouldn't a single instance
be enough? Thus having a single instance for the whole app would do it. I
don't think it's the case.
On Mon, Oct 27, 2014 at 10:21 PM, Savvas Andreas Moysidis <
savvas.andreas.moysi...@gmail.com> wrote:
> The question, I suppose, is whether Client implementations are
> thread-safe or not which is something that is not stipulated by the
> interface contract.
>
> If they are(something which is sort of implied by the javadoc), then
> you could maybe declare and use a single instance like the following? (in
> a
> JavaEE context)
>
> @Singleton
> public class SomeService {
>
> private Client restClient;
>
> @PostConstruct
> private void init() {
> restClient = ClientBuilder.newClient();
> }
>
> .
> // Use restClient object here
>
> .
>
> @PreDestroy
> private void cleanUp() {
> restClient.close();
> }
> }
>
> On 27 October 2014 23:24, Mario Diana wrote:
>
>> I'd be interested in hearing what common practice is regarding pooled
>> Client objects, too. Do people use the Apache objects pool library?
>> That's
>> the only option I've heard of. Are there other mainstream solutions?
>>
>> Mario
>>
>> > On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa <
>> rodrigo.uc...@gmail.com> wrote:
>> >
>> > [...]
>>
>> > How should we implement a pool of Client objects in this scenario?
>> Is there a common solution?
>> >
>> > Regards,
>> > Rodrigo Uchoa.
>>
>>
>>
>> --
>> ___
>> Resteasy-users mailing list
Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
(*) meant to say: "...the method for generating *WebTarget*s"!
On 28 October 2014 23:37, Savvas Andreas Moysidis <
savvas.andreas.moysi...@gmail.com> wrote:
>
> right...took a quick look at the jsr spec (
> http://download.oracle.com/otn-pub/jcp/jaxrs-2_0-fr-eval-spec/jsr339-jaxrs-2.0-final-spec.pdf)
> but nothing seems to be mentioned about thread-safety in client-api
> implementations...so, this seems to largely be an implementation property
> rather than a spec requirement..
>
> anyway, I dug through the implementation I am using (
> *org.glassfish.jersey.client.JerseyClient*) and from what I can see the
> method for generating *WebRequest*s at least seems to be perfectly
> thread-safe:
>
> @Override
> public JerseyWebTarget target(String uri) {
> checkNotClosed();
> checkNotNull(uri, LocalizationMessages.CLIENT_URI_TEMPLATE_NULL());
> return new JerseyWebTarget(uri, this);
> }
>
> (note: checkNotNull is some preconditions-checking library statically
> imported and LocalizationMessages.CLIENT_URI_TEMPLATE_NULL() is an actual
> method call using a bizarre naming convention I've never come across
> before... )
>
> with checkNotClosed() having an implementation of:
> void checkNotClosed() {
> checkState(!closedFlag.get(),
> LocalizationMessages.CLIENT_INSTANCE_CLOSED());
> }
>
> and with the class variable closedFlag declared as:
> private final AtomicBoolean closedFlag = new AtomicBoolean(false);
>
> which of course is thread-safe.
>
> So, using a single instance and invoking only the various flavours of the
> target() method seems to be safe. Wouldn't be so sure about the various
> provider registration methods though...
>
> Savvas
>
> On 28 October 2014 12:40, Rodrigo Uchôa wrote:
>
>> Savvas,
>>
>> I have no evidence whatsoever. :)
>>
>> But it seems strange to me that if implementations should be thread-safe,
>> this information is not written in bold in the javadocs :) Or it could be
>> decision left up to vendors to decide.
>>
>> Anyway, if it is indeed thread-safe it makes things a lot easier since a
>> single instance can be used throughout the app.
>>
>> On Tue, Oct 28, 2014 at 7:50 AM, Savvas Andreas Moysidis <
>> savvas.andreas.moysi...@gmail.com> wrote:
>>
>>> Hi Rodrigo,
>>>
>>> That's precisely what my example above showcases. :)
>>>
>>> It may well be the case that the Client class is not thread-safe indeed
>>> but can I ask though what evidence have you got to believe that?
>>>
>>> Perhaps taking a look at the source code would clarify things? (or a
>>> commiter following this thread could verify instead)
>>>
>>> On 28 October 2014 01:23, Rodrigo Uchôa wrote:
>>>
if Client implementations are thread-safe, shouldn't a single instance
be enough? Thus having a single instance for the whole app would do it. I
don't think it's the case.
On Mon, Oct 27, 2014 at 10:21 PM, Savvas Andreas Moysidis <
savvas.andreas.moysi...@gmail.com> wrote:
> The question, I suppose, is whether Client implementations are
> thread-safe or not which is something that is not stipulated by the
> interface contract.
>
> If they are(something which is sort of implied by the javadoc), then
> you could maybe declare and use a single instance like the following? (in
> a
> JavaEE context)
>
> @Singleton
> public class SomeService {
>
> private Client restClient;
>
> @PostConstruct
> private void init() {
> restClient = ClientBuilder.newClient();
> }
>
> .
> // Use restClient object here
>
> .
>
> @PreDestroy
> private void cleanUp() {
> restClient.close();
> }
> }
>
> On 27 October 2014 23:24, Mario Diana wrote:
>
>> I'd be interested in hearing what common practice is regarding pooled
>> Client objects, too. Do people use the Apache objects pool library?
>> That's
>> the only option I've heard of. Are there other mainstream solutions?
>>
>> Mario
>>
>> > On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa <
>> rodrigo.uc...@gmail.com> wrote:
>> >
>> > [...]
>>
>> > How should we implement a pool of Client objects in this scenario?
>> Is there a common solution?
>> >
>> > Regards,
>> > Rodrigo Uchoa.
>>
>>
>>
>> --
>> ___
>> Resteasy-users mailing list
>> Resteasy-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>
>
>
>
> --
>
> ___
> Rest
Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
right...took a quick look at the jsr spec (
http://download.oracle.com/otn-pub/jcp/jaxrs-2_0-fr-eval-spec/jsr339-jaxrs-2.0-final-spec.pdf)
but nothing seems to be mentioned about thread-safety in client-api
implementations...so, this seems to largely be an implementation property
rather than a spec requirement..
anyway, I dug through the implementation I am using (
*org.glassfish.jersey.client.JerseyClient*) and from what I can see the
method for generating *WebRequest*s at least seems to be perfectly
thread-safe:
@Override
public JerseyWebTarget target(String uri) {
checkNotClosed();
checkNotNull(uri, LocalizationMessages.CLIENT_URI_TEMPLATE_NULL());
return new JerseyWebTarget(uri, this);
}
(note: checkNotNull is some preconditions-checking library statically
imported and LocalizationMessages.CLIENT_URI_TEMPLATE_NULL() is an actual
method call using a bizarre naming convention I've never come across
before... )
with checkNotClosed() having an implementation of:
void checkNotClosed() {
checkState(!closedFlag.get(),
LocalizationMessages.CLIENT_INSTANCE_CLOSED());
}
and with the class variable closedFlag declared as:
private final AtomicBoolean closedFlag = new AtomicBoolean(false);
which of course is thread-safe.
So, using a single instance and invoking only the various flavours of the
target() method seems to be safe. Wouldn't be so sure about the various
provider registration methods though...
Savvas
On 28 October 2014 12:40, Rodrigo Uchôa wrote:
> Savvas,
>
> I have no evidence whatsoever. :)
>
> But it seems strange to me that if implementations should be thread-safe,
> this information is not written in bold in the javadocs :) Or it could be
> decision left up to vendors to decide.
>
> Anyway, if it is indeed thread-safe it makes things a lot easier since a
> single instance can be used throughout the app.
>
> On Tue, Oct 28, 2014 at 7:50 AM, Savvas Andreas Moysidis <
> savvas.andreas.moysi...@gmail.com> wrote:
>
>> Hi Rodrigo,
>>
>> That's precisely what my example above showcases. :)
>>
>> It may well be the case that the Client class is not thread-safe indeed
>> but can I ask though what evidence have you got to believe that?
>>
>> Perhaps taking a look at the source code would clarify things? (or a
>> commiter following this thread could verify instead)
>>
>> On 28 October 2014 01:23, Rodrigo Uchôa wrote:
>>
>>> if Client implementations are thread-safe, shouldn't a single instance
>>> be enough? Thus having a single instance for the whole app would do it. I
>>> don't think it's the case.
>>>
>>> On Mon, Oct 27, 2014 at 10:21 PM, Savvas Andreas Moysidis <
>>> savvas.andreas.moysi...@gmail.com> wrote:
>>>
The question, I suppose, is whether Client implementations are
thread-safe or not which is something that is not stipulated by the
interface contract.
If they are(something which is sort of implied by the javadoc), then
you could maybe declare and use a single instance like the following? (in a
JavaEE context)
@Singleton
public class SomeService {
private Client restClient;
@PostConstruct
private void init() {
restClient = ClientBuilder.newClient();
}
.
// Use restClient object here
.
@PreDestroy
private void cleanUp() {
restClient.close();
}
}
On 27 October 2014 23:24, Mario Diana wrote:
> I'd be interested in hearing what common practice is regarding pooled
> Client objects, too. Do people use the Apache objects pool library? That's
> the only option I've heard of. Are there other mainstream solutions?
>
> Mario
>
> > On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa
> wrote:
> >
> > [...]
>
> > How should we implement a pool of Client objects in this scenario?
> Is there a common solution?
> >
> > Regards,
> > Rodrigo Uchoa.
>
>
>
> --
> ___
> Resteasy-users mailing list
> Resteasy-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>>
>>>
>>> --
>>>
>>> ___
>>> Resteasy-users mailing list
>>> Resteasy-users@lists.sourceforge.net
>>> https:/
Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
Savvas,
I have no evidence whatsoever. :)
But it seems strange to me that if implementations should be thread-safe,
this information is not written in bold in the javadocs :) Or it could be
decision left up to vendors to decide.
Anyway, if it is indeed thread-safe it makes things a lot easier since a
single instance can be used throughout the app.
On Tue, Oct 28, 2014 at 7:50 AM, Savvas Andreas Moysidis <
savvas.andreas.moysi...@gmail.com> wrote:
> Hi Rodrigo,
>
> That's precisely what my example above showcases. :)
>
> It may well be the case that the Client class is not thread-safe indeed
> but can I ask though what evidence have you got to believe that?
>
> Perhaps taking a look at the source code would clarify things? (or a
> commiter following this thread could verify instead)
>
> On 28 October 2014 01:23, Rodrigo Uchôa wrote:
>
>> if Client implementations are thread-safe, shouldn't a single instance be
>> enough? Thus having a single instance for the whole app would do it. I
>> don't think it's the case.
>>
>> On Mon, Oct 27, 2014 at 10:21 PM, Savvas Andreas Moysidis <
>> savvas.andreas.moysi...@gmail.com> wrote:
>>
>>> The question, I suppose, is whether Client implementations are
>>> thread-safe or not which is something that is not stipulated by the
>>> interface contract.
>>>
>>> If they are(something which is sort of implied by the javadoc), then you
>>> could maybe declare and use a single instance like the following? (in a
>>> JavaEE context)
>>>
>>> @Singleton
>>> public class SomeService {
>>>
>>> private Client restClient;
>>>
>>> @PostConstruct
>>> private void init() {
>>> restClient = ClientBuilder.newClient();
>>> }
>>> .
>>> // Use restClient object here
>>> .
>>>
>>> @PreDestroy
>>> private void cleanUp() {
>>> restClient.close();
>>> }
>>> }
>>>
>>> On 27 October 2014 23:24, Mario Diana wrote:
>>>
I'd be interested in hearing what common practice is regarding pooled
Client objects, too. Do people use the Apache objects pool library? That's
the only option I've heard of. Are there other mainstream solutions?
Mario
> On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa
wrote:
>
> [...]
> How should we implement a pool of Client objects in this scenario? Is
there a common solution?
>
> Regards,
> Rodrigo Uchoa.
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>>
>>>
>>>
>>> --
>>>
>>> ___
>>> Resteasy-users mailing list
>>> Resteasy-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>>
>>>
>>
>>
>> --
>>
>> ___
>> Resteasy-users mailing list
>> Resteasy-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>
>>
>
>
> --
>
> ___
> Resteasy-users mailing list
> Resteasy-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
Hi Rodrigo,
That's precisely what my example above showcases. :)
It may well be the case that the Client class is not thread-safe indeed but
can I ask though what evidence have you got to believe that?
Perhaps taking a look at the source code would clarify things? (or a
commiter following this thread could verify instead)
On 28 October 2014 01:23, Rodrigo Uchôa wrote:
> if Client implementations are thread-safe, shouldn't a single instance be
> enough? Thus having a single instance for the whole app would do it. I
> don't think it's the case.
>
> On Mon, Oct 27, 2014 at 10:21 PM, Savvas Andreas Moysidis <
> savvas.andreas.moysi...@gmail.com> wrote:
>
>> The question, I suppose, is whether Client implementations are
>> thread-safe or not which is something that is not stipulated by the
>> interface contract.
>>
>> If they are(something which is sort of implied by the javadoc), then you
>> could maybe declare and use a single instance like the following? (in a
>> JavaEE context)
>>
>> @Singleton
>> public class SomeService {
>>
>> private Client restClient;
>>
>> @PostConstruct
>> private void init() {
>> restClient = ClientBuilder.newClient();
>> }
>> .
>> // Use restClient object here
>> .
>>
>> @PreDestroy
>> private void cleanUp() {
>> restClient.close();
>> }
>> }
>>
>> On 27 October 2014 23:24, Mario Diana wrote:
>>
>>> I'd be interested in hearing what common practice is regarding pooled
>>> Client objects, too. Do people use the Apache objects pool library? That's
>>> the only option I've heard of. Are there other mainstream solutions?
>>>
>>> Mario
>>>
>>> > On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa
>>> wrote:
>>> >
>>> > [...]
>>>
>>> > How should we implement a pool of Client objects in this scenario? Is
>>> there a common solution?
>>> >
>>> > Regards,
>>> > Rodrigo Uchoa.
>>>
>>>
>>>
>>> --
>>> ___
>>> Resteasy-users mailing list
>>> Resteasy-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>>
>>
>>
>>
>> --
>>
>> ___
>> Resteasy-users mailing list
>> Resteasy-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>
>>
>
>
> --
>
> ___
> Resteasy-users mailing list
> Resteasy-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
if Client implementations are thread-safe, shouldn't a single instance be
enough? Thus having a single instance for the whole app would do it. I
don't think it's the case.
On Mon, Oct 27, 2014 at 10:21 PM, Savvas Andreas Moysidis <
savvas.andreas.moysi...@gmail.com> wrote:
> The question, I suppose, is whether Client implementations are thread-safe
> or not which is something that is not stipulated by the interface contract.
>
> If they are(something which is sort of implied by the javadoc), then you
> could maybe declare and use a single instance like the following? (in a
> JavaEE context)
>
> @Singleton
> public class SomeService {
>
> private Client restClient;
>
> @PostConstruct
> private void init() {
> restClient = ClientBuilder.newClient();
> }
> .
> // Use restClient object here
> .
>
> @PreDestroy
> private void cleanUp() {
> restClient.close();
> }
> }
>
> On 27 October 2014 23:24, Mario Diana wrote:
>
>> I'd be interested in hearing what common practice is regarding pooled
>> Client objects, too. Do people use the Apache objects pool library? That's
>> the only option I've heard of. Are there other mainstream solutions?
>>
>> Mario
>>
>> > On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa
>> wrote:
>> >
>> > [...]
>>
>> > How should we implement a pool of Client objects in this scenario? Is
>> there a common solution?
>> >
>> > Regards,
>> > Rodrigo Uchoa.
>>
>>
>>
>> --
>> ___
>> Resteasy-users mailing list
>> Resteasy-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>>
>
>
>
> --
>
> ___
> Resteasy-users mailing list
> Resteasy-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
The question, I suppose, is whether Client implementations are thread-safe
or not which is something that is not stipulated by the interface contract.
If they are(something which is sort of implied by the javadoc), then you
could maybe declare and use a single instance like the following? (in a
JavaEE context)
@Singleton
public class SomeService {
private Client restClient;
@PostConstruct
private void init() {
restClient = ClientBuilder.newClient();
}
.
// Use restClient object here
.
@PreDestroy
private void cleanUp() {
restClient.close();
}
}
On 27 October 2014 23:24, Mario Diana wrote:
> I'd be interested in hearing what common practice is regarding pooled
> Client objects, too. Do people use the Apache objects pool library? That's
> the only option I've heard of. Are there other mainstream solutions?
>
> Mario
>
> > On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa
> wrote:
> >
> > [...]
>
> > How should we implement a pool of Client objects in this scenario? Is
> there a common solution?
> >
> > Regards,
> > Rodrigo Uchoa.
>
>
>
> --
> ___
> Resteasy-users mailing list
> Resteasy-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
--
___
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
Re: [Resteasy-users] Pool for javax.ws.rs.client.Client objects?
I'd be interested in hearing what common practice is regarding pooled Client objects, too. Do people use the Apache objects pool library? That's the only option I've heard of. Are there other mainstream solutions? Mario > On Oct 27, 2014, at 12:39 PM, Rodrigo Uchôa wrote: > > [...] > How should we implement a pool of Client objects in this scenario? Is there a > common solution? > > Regards, > Rodrigo Uchoa. -- ___ Resteasy-users mailing list Resteasy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/resteasy-users
