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
