Non-extendability was criticized by my long before JAX-RS 1.0 was
finalized and widely adopted, but it was your former team member Marc
Hadley that said that he doesn't want to discuss that again with the JSR
311 expert group and that he wants to move the discussion to JAX-RS 2.0.
As an JSR 339 EG member I will announce hereby that I WILL discuss that
in the EG and I hope that the Jersey team will be supporting me in that
way independent of its complexity, because you see, it IS a heavy
problem and MUST be solved, even by breaking backwards compatibility.
Keeping compatibility is NOT a solution and leads to trouble.
Regards
Markus
From: Pavel Bucek [mailto:pavel.bucek_at_oracle.com]
Sent: Donnerstag, 24. Februar 2011 15:33
To: users_at_jersey.java.net
Subject: [Jersey] Re: Enum<ClientResponse.Status> vs.
Enum<Response.Status>
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