jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Re: Comments about container filters

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Mon, 17 Sep 2012 16:42:14 +0100

On 17/09/12 16:20, Marek Potociar wrote:
>
> On Sep 17, 2012, at 12:53 PM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>
>>
>>>>>>
>>>>>>>> 7. ContainerResponseContext.getHeaders& getStringHeaders - both return mutable maps, the latter method only supports remove operations: can we have getHeaders() only ? A single method dedicated to modifying response headers ?
>>>>>>>
>>>>>>> The getStringHeaders() provide a convenient string-based view of getHeaders(). There are many cases where this is useful. We may updated the javadoc so that getStringHeaders() do not indicate support for removal operations, if you want, but the method should stay.
>>>>>>>
>>>>>> If you can agree to make this view read only then it would simply things IMHO
>>>>>
>>>>> Ok, I don't have any problems with removing the mutability requirement from the javadoc.
>>>>
>>>> That simplifies things a bit
>>>
>>> Done.
>>
>> Can you please do the same for ClientRequestContext ?
>
> Done.
>
Cool. One thing which is worth clarifying is that
ContainerResponseFilters are skipped in case of escaped Exceptions, ie,
in cases when no mapper has been found - this is because no mapping
between the escaped Exception and Response properties exist.

Agreed ?

Sergey

> Marek
>
>>
>> Have few more questions.
>>
>> 1. Is it ValidationException when we have different filter classes having the same NameBinding value ?
>>
>> 2. BindingPriority documentation say that PostMatch filters have to be sorted in the reverse order, however it also mentions "response" filters in that context. So, do all the post-match filters have to be sorted in the reverse order, or only the response filters
>>
>> Sergey
>>
>>>
>>> Marek
>>>>
>