[JERSEY-77] Allow null entity in HTTP method verification Created: 03/Jun/08
Updated:
10/Sep/15 Resolved: 05/Jun/08
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Closed
jersey
core
None
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Environment:
Bug
zeroorone
Fixed
None
Not Specified
Issuezilla Id:
77
1.0
Priority:
Assignee:
Votes:
Critical
jersey-issues
0
Not Specified
Not Specified
Operating System: Windows XP
Platform: All
Description
I would like to be able to have my service method return null in certain circumstances, as
illustrated in the
following sample code:
@Path("/item")
@Singleton
public class ItemService {
@GET
public synchronized Item get(@QueryParam("id") int id)
{ return ItemManager.find(id); // may return null }
}
However, in doing so a runtime exception is thrown (javax.ws.rs.WebApplicationException)
because the
verifyResponse method of the HttpMethodRule class is imposing a rule restricting the entity
(return value) from
being null. This doesn't make much sense to me as I have implemented a MessageBodyWriter
for the Item class
that is capable of correctly serializing a null value in the JSON representation (i.e., "null"). I
would like for this
check to be removed so that a null value is provided to any applicable MessageBodyWriter,
giving that writer the
chance to handle the null value appropriately.
I understand the intension of this check, however, it seems perfectly reasonable to me that a
service whose
content-type is "application/json" could return null (so long as the representation of null in the
response is
appropriate for that content-type).
RFC2616 (section14.13) states that "Any Content-Length greater than or equal to zero is a valid
value". Similarly,
section 4.3 states that "All 1xx (informational), 204 (no content), and 304 (not modified)
responses MUST NOT
include a message-body. All other responses do include a message-body, although it MAY be
of zero length." Therefore, it should even be acceptable for the MessageBodyWriter to ignore
the null value (entity), writing
nothing to the body of the response.
Comments
Comment by sandoz [ 03/Jun/08 ]
I agree there is an issue here, a similar issue was recently raised on the
Jersey users list.
The 311 spec defines the returning of null to mean a 204.
Jersey/JAX-RS selects a MessageBodyReader (MBW) using the class/type of the
returned instance (not from the return type of the resource method) and produced
media type. If null is returned then there is no class/type available and no MBW
will be selected.
So i plan to remove the check but it will not enable what you want.
Comment by zeroorone [ 03/Jun/08 ]
Fair enough. However, could the class/type of the return type of the annotated method be used
as a
default when the instance type cannot be determined (I believe null is the only case)?
In any case, if a 204 is returned, I believe that would be acceptable for the short term. Our client
just
needs some indication that nothing is returned, so a 204 should suffice in lieu of a null JSON
object in the
response body. Thanks.
Comment by sandoz [ 03/Jun/08 ]
What happens if the return type is changed to be Response or Object?
I have things queued up to fix things this week so that a 204 is returned.
Comment by zeroorone [ 03/Jun/08 ]
I don't think I understand the question very well, but I'll give my thoughts.
If the return type were Response or Object and the method returned null, I would presume that
only
MB(Reader/Writer)s specifically designed to serialize/deserialize Responses or Objects would
be used. I
wouldn't presume that the code could be smart enough to determine what was desired vs what
was
written. In my example, if the return type was object, then I would not assume that my MBW
would be
given a chance to serialize. But, in my case, Item is an interface so I would presume that a
MBW built to
serialize instances of that interface would be given a chance to handle any return values,
including null.
This seems relatively straight forward, unless there is something I am missing (maybe a poor
understanding of the consequences of using the Response/Object as a return type). Thanks
again.
Comment by sandoz [ 03/Jun/08 ]
Response is a special JAX-RS type for returning HTTP meta-data and an entity. So
an MBW will never operate on a Response. It means one can do this:
@GET
Response get()
{ Item i = ... return Response.ok(i).build(); }
or:
@GET
Object get() { Item i = ... return Response.ok(i).build(); }
or:
@GET
Object get()
{ Item i = ... return i; }
You can change the return type of your method signature without affecting the
resulting behavior.
Comment by zeroorone [ 03/Jun/08 ]
With the object return type, returning a null value directly caused the same problem.
With the object or response return type, returning a response wrapping the null value in the ok
method
seemed to work appropriately.
Hopefully that answers your original question effectively. However, I do want the MBW to
operate in the
long run.
Comment by sandoz [ 04/Jun/08 ]
Things now conform to the 311 specification:

A null return value will result in a 204 with no entity.

A return of Response.ok(null).build() will result in a 200 with no entity.
Comment by zeroorone [ 05/Jun/08 ]
I confirm this has been fixed in the latest dev build.
Generated at Fri Feb 05 11:12:14 UTC 2016 using JIRA 6.2.3#6260sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.