Thanks.
Not sure I agree that static is evil in all cases. I use it sometimes where it fits. Mostly to declare final constants, but I can agree that it's probably mostly out of convenience as opposed to making a class with a private constructor and factory creation method and make sure only one instance is ever created.
--- On Mon, 7/11/11, Ryan Stewart <rds6235_at_gmail.com> wrote:
From: Ryan Stewart <rds6235_at_gmail.com>
Subject: [Jersey] Re: What is the right way to handle threading with jersey client
To: users_at_jersey.java.net
Date: Monday, July 11, 2011, 6:12 PM
On Mon, Jul 11, 2011 at 6:53 PM, Kevin Duffey <andjarnic_at_yahoo.com> wrote:
Hi,
I read that. From that I gather that I should create a static single instance of Client, shared across all threads, all classes that would use it to create resources.. is that correct?
That would be one way to do it. It depends on how you've designed your app to handle resources. In my case, the Client and WebResource instances are created once by a Spring bean of singleton scope. I'd never use static for something like that. Static is evil. For instance:
http://corfield.org/entry/Static_is_Evil
Where I am not sure of is the WebResource. In my case I may end up with 100's of different urls/paths to send requests to. For each I'd have to create a new WebResource instance I believe. However, if after a given url/path Webresource is created I may need it again to send more requests to, I assume from this doc that I should keep the instance around to reuse it and that it too is thread safe. So for any reason if various threads (say different users) are sending something to the same url/path, I'd use the same one WebResource instance and calling methods on it from different threads is safe?
Yes, a WebResource is also thread-safe, as the docs say. A WebResource.Builder, on the other hand, is not. Keep your Client and WebResource instances around if it's feasible.