Declaring a variable and initializing it to null is a warning flag in
general. Try to defer declaring a variable until you have the value for it,
then the proper scope will follow.
Either have it as a final (and initialized) instance variable:
protected final Client jerseyClient = ClientBuilder.newBuilder().
register(JacksonFeature.class).build();
Or a local variable in your method:
WebTarget jerseyTarget = jerseyClient.target(baseUrl).
path("api").path("v1");
On Thu, Dec 11, 2014 at 5:32 PM, Sobieralski, Damian Michael <
dsobiera_at_indiana.edu> wrote:
> I have a question about thread safety here. This is a much lower level
> discussion than what have been reading here and touches on Java threading
> 101.
>
> In a backend service object (we have something like this - this object
> sits in a servlet container):
>
> protected Client jerseyClient = null;
> protected WebTarget jerseyTarget = null;
>
> These are class variables. This is normally a warning flag for threading
> issues
>
> Then we have code like this:
>
> protected void readyConnection() throws Exception {
> jerseyClient =
> ClientBuilder.newBuilder().register(JacksonFeature.class).build();
>
> jerseyTarget =
> jerseyClient.target(baseUrl).path("api").path("v1");
> }
>
> and methods that use jerseyTarget. Is this a bad idea thread wise? It
> seems like jersey client is fine being a class variable. But that
> jerseyTarget in this ready method instead of setting the class variable
> jerseyTarget should return its own jerseyTarget.
>
> So, is it better to do this?
>
> protected WebTarget readyConnection() throws Exception {
> jerseyClient =
> ClientBuilder.newBuilder().register(JacksonFeature.class).build();
>
> return jerseyClient.target(baseUrl).path("api").path("v1");
> }
>
> - Damian
>
>
--
Mikael Ståldal
Chief Software Architect
*Appear*
Phone: +46 8 545 91 572
Email: mikael.staldal_at_appearnetworks.com