users@jersey.java.net

Re: [Jersey] Using client apis on server (or calling a REST service from a REST service)

From: Andrew Ochsner <aochsner_at_cs.stanford.edu>
Date: Tue, 3 Nov 2009 11:23:45 -0600

Thank you all for the suggestions. Allowing injection of a pre-configured
Client or WebResource sounds like it would be nice. To be honest, I gave it
some thought and my use case is so simple (ping another REST service we
interact with) that I just went w/ a static WebResource singleton. Really
no reason to be any more complex than that...this interface will be hit by 1
thread every ten min or so anyways.

Thanks!
Andy O

On Tue, Nov 3, 2009 at 1:58 AM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:

> Hi,
>
> Another option i have been thinking about is to allow injection of
> pre-configured Client or WebResource instances. Just need to get around to
> implementing something.
>
>
> If you want to use Jersey's simple injection capability you can do:
>
> @Singleton
> public class ClientHolder {
> private final Client c;
>
> public ClientHolder() {
> c = Client.create();
> }
>
> public Client getClient() {
> return c;
> }
>
> @PreDestroy
> public void destroy() {
> c.destroy();
> }
> }
>
>
> @Path("/")
> public class MyResource {
> public MyResource(@Context ResourceContext rc) {
> Client c = rc.get(ClientHolder.class).getClient();
> }
> }
>
> or you can use the InjectableProvider functionality, which i can provide
> more details if you wish.
>
> Of course if you are using Guice or Spring you can use their injection
> facilities which are more powerful/featured than Jersey.
>
> Paul.
>
>
> On Nov 2, 2009, at 11:54 PM, Craig McClanahan wrote:
>
> On Mon, Nov 2, 2009 at 2:08 PM, Andrew Ochsner <aochsner_at_cs.stanford.edu>
>> wrote:
>>
>>> Hi:
>>>
>>> Given that Client instances are expensive to create, is there a good
>>> solution/approach to creating/destroying these in the context of a
>>> Resource
>>> (which currently is using per-thread instantiation)? I'm not doing
>>> anything
>>> complicated, just curious if there's a best practice for these sorts of
>>> things
>>>
>>> Thanks
>>> Andy O
>>>
>>>
>> I would take a look at instantiating a single client instance (for
>> each server that you need to contact), and storing these instances in
>> application scope (i.e. servlet context attributes in a webapp) and
>> then use them to create new WebResource instances on the fly in your
>> resource methods. As long as you don't try wild things like changing
>> the set of filters associated with a client on the fly, creating new
>> WebResource instances should be threadsafe.
>>
>> Another alternative would be to precreate a pool of Client instances,
>> and have your resource methods "check out" a client instance, use it,
>> and check it back in -- analogous to the way that JDBC connection
>> pools work. You'd ideally want to have the pool dynamically
>> expandable up to the maximum number of simultaneous request processing
>> threads you are configured for, or precreate that many of them ahead
>> of time.
>>
>> A third choice would be to use a thread local variable containing
>> Client instances, keyed by the current thread (Thread. in your
>> resource classes (probably in an abstract base class to centralize the
>> logic), and only create a Client instance the first time a particular
>> request thread needs one. The tricky part of this approach, however,
>> is how to clean up these Client instances. A ServletContextListener
>> can help you deal with application shutdown, but I don't see any
>> reliable way to deal with the fact that your servlet container might
>> decide to throw away a request processing thread (instead of pooling
>> and reusing them) any time it wants to -- with no notification to your
>> app that this thread is no longer in use, so any Client instance
>> cached for it can be thrown away.
>>
>> Craig
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>