users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: HEADS-UP: Late change to resolve spec/javadoc inconsistencies around reading zero-length entities

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Mon, 25 Mar 2013 11:39:51 +0100

On Mar 25, 2013, at 9:09 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:

> Hi
> On 22/03/13 21:24, Marek Potociar wrote:
>> Hello experts,
>> please review the http://java.net/jira/browse/JAX_RS_SPEC-390 issue
>> including the comments that contain the resolution description.
>>
>> This late change was unfortunately necessary to fix the inconsistency
>> between spec text and Response javadoc. Also, the old spec text was
>> neglecting the scenarios where message body readers are used on the
>> client side to read the response entities and throwing
>> BadRequestException would be inappropriate in such case.
>
> This text, "MBR.readFrom documentation will be updated to mention that if MBR is not able to produce an instance that would represent an empty content, it is expected to throw NoContentException (an IOException subclass) and not return null.",
>
> Would it break the applications written to expect that the empty non-XML/JAXB payloads are represented as null ? AFAIK, only JAXB providers were expected to return 400 if they could not read the body.

I don't think so. We say what's expected and recommended behavior, we do not enforce it. If some MBR returns null, then null should be used. Even though I think it is a really bad practice to represent empty content as null and thus it makes sense to say that it's recommended for MBRs to return a non-null empty representations. Also, note that I'm not changing the semantics of the previous version of the text here at all.
>
> If I do a an empty form payload, this is obviously valid too (example, a relevant @FormParam parameter would return 'null').

I think we entered a grey area of the spec here. I cannot see anything in the spec that would confirm that returning null is a valid thing to do. Yet I cannot see anything that would say it is not a valid behavior either. In any case, IMO the new wording does not preclude any of the two options.

Also note that Form MBR return value is not directly related to value injected by FormParam. Form MBR can return a (possibly empty) Form instance and FormParam can still inject null for form fields not present in the Form.

Marek

>
> Sergey
>
>
>
>>
>> Thank you,
>> Marek
>