(*) 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 <rodrigo.uc...@gmail.com> 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 <rodrigo.uc...@gmail.com> 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 <mariodi...@gmail.com> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> 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
