users@jersey.java.net

[Jersey] Re: Enum<ClientResponse.Status> vs. Enum<Response.Status>

From: Pavel Bucek <pavel.bucek_at_oracle.com>
Date: Thu, 24 Feb 2011 15:32:50 +0100

Hello Casper,

see http://java.net/jira/browse/JERSEY-151

it is not the same API. But.. you are right, the intersection of
Response.Status and ClientResponse.Status is not empty which is
confising. Problem is that Response.Status is an enum and enums can't be
extended. So.. there is no easy fix, at least not in Jersey 1.x, because
changing it implies spec change (Response.Status is in jsr311-api) and
this one would be non-trivial, so I don't think it will happen. It will
be probably different in JAX-RS 2.0 if the client api will be part of
the specification.

I'm not really sure what we can do for you now, only thing I can suggest
now is "double check your imports". Maybe others would like to comment too..

Regards,
Pavel


On 02/23/2011 10:25 PM, Casper Bang wrote:
> In writing unit-tests I find myself constantly importing the wrong
> Status package, resulting in some puzzling assertSame errors:
>
> expected same:<See Other> was not:<See Other>
>
> If one uses assertEquals, the assertion reveals a bit more:
>
> expected: javax.ws.rs.core.Response$Status<See Other> but was:
> com.sun.jersey.api.client.ClientResponse$Status<See Other>
>
> I suppose one could always resort to comparing raw response codes, but
> it's long and crude:
>
> assertEquals(Status.SEE_OTHER.getStatusCode(),
> response.getClientResponseStatus().getStatusCode());
>
> Invoking equals manually on one of the Enum's makes for worse test
> output, but at least my IDE (NetBeans) will flag it as a warning:
>
>
> assertTrue(Status.SEE_OTHER.equals(response.getClientResponseStatus()));
>
> The shortest type-safe way appears to be useing this idiom, though it
> doesn't make for nice test failure messages:
>
> assertTrue(Status.SEE_OTHER ==
> response.getClientResponseStatus());
>
>
> Is there a good reason for, in the same API, defining both
> Enum<ClientResponse.Status> and Enum<Response.Status> which confuses
> humans and IDE's? As an API consumer, It feels a little like the
> Enum's got a bit too much responsibility and could benefit from
> composition instead. Or am I missing something?
>
> Sincerely,
> Casper
>
>