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...
Cheers. Sergey
> Marek
>
>>
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>