users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Should null values in client entity variant overwrite Content-* headers?

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Tue, 12 Nov 2013 13:34:22 +0100

On 11 Nov 2013, at 18:47, Bill Burke <bburke_at_redhat.com> wrote:

> On 11/11/2013 7:59 AM, Sergey Beryozkin wrote:
>> Hi All,
>> On 11/11/13 12:17, Marek Potociar wrote:
>>>
>>> On 08 Nov 2013, at 22:52, Bill Burke <bburke_at_redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On 11/8/2013 4:47 PM, Marek Potociar wrote:
>>>>>
>>>>> On 08 Nov 2013, at 17:31, Bill Burke <bburke_at_redhat.com> wrote:
>>>>>
>>>>>> Its not covered by the TCK as we pass the TCK :)
>>>>>>
>>>>>> But, you're changing the behavior of Variant post spec release.
>>>>>> Thought that was a no-no?
>>>>>
>>>>> Am I? All I am suggesting is that if the Variant field contains
>>>>> null, then this null value should not override any existing header
>>>>> previously set by the user in the client request. My suggestion is
>>>>> based on the fact that relevant javadoc is not strict in that
>>>>> respect. Please point me to the part of the spec I'm changing and I
>>>>> reconsider (and most likely take back) my proposal.
>>>>>
>>>>
>>>> Didn't you point it out yourself? The Javadoc in any of the Invoker
>>>> methods states:
>>>>
>>>>
>>>> * Any variant-related HTTP headers previously set
>>>> (namely {_at_code Content-Type},
>>>> * {_at_code Content-Language} and {_at_code
>>>> Content-Encoding}) will be overwritten using
>>>> * the entity variant information.
>>>
>>> I am not suggesting to change the javadoc (now) - I am suggesting to
>>> change implementation to be in line with my initial intentions when I
>>> wrote the javadoc - IIRC, the use case of null Variant field values
>>> overriding headers did not occur to me and the note about overwriting
>>> was written with non-null fields in mind. What I'm trying to do now is
>>> to reach an agreement on a coordinated update in those implementations
>>> that take this unfortunate javadoc sentence (too) literally.
>>>
>>> In any case, if you still object to changing our implementations, I'm
>>> (not happy but) fine with keeping things as they are.
>>>
>> I wonder why would Bill really object given he referred to it as a
>> mistake :-) and Marek being open for a fix ? Keeping it as is not a
>> major issue from my point of view, I can tweak the CXF code but...
>>
>
> Not against the change. Just thought it was illegal.
>
> Bill

It is not covered by TCK and I consider our impl. to be sort of a bug. (Our users in fact report it as a bug.) So I do not see it to be illegal. Am I missing something?

Marek