On Sep 12, 2012, at 12:12 PM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> On 12/09/12 10:55, Marek Potociar wrote:
>> All right,
>>
>> One more iteration on the subject: *We MUST support response filters
>> that are executed even if a resource has been matched. *
>>
> Not sure why you are highlighting, thought it was obvious
Well, since @PreMatching was dropped for the response filters (based on your suggestion), the Bill's sentence:
>>>> IMO, no filters should be executed until the resource method is
>>>> matched except for PreMatch filters.
(also from the context) seems to suggest no response filters should be run if pre-matching request filter aborts the processing with a response.
>
>> Just one trivial use case for all: LoggingFilter. It has to be able log
>> responses even in cases when the resource has not been matched and it
>> cannot be implemented as WriterInterceptor as responses do not have to
>> have an entity. There may be other relevant use cases when e.g. some
>> response header decorating filters need to be applied globally.
>>
>> So, when it comes to response filters, then I suggest:
>>
>> - global, (that is not name-bound) response filters are applied to any
>> response (regardless of resource matching result)
>> - name-bound response filters (including those bound directly to the
>> Application) would be applied only if a resource has been matched.
>>
>
> Agreed. Have you seen the other email where I also proposed dropping '_at_PreMatching' from the docs for response filters ?
I obviously did. See above.
Marek
>
> Sergey
>
>> Marek
>>
>> On Sep 10, 2012, at 6:23 PM, Marek Potociar <marek.potociar_at_oracle.com
>> <mailto:marek.potociar_at_oracle.com>> wrote:
>>
>>> Fixed,
>>>
>>> Marek
>>>
>>> On Sep 10, 2012, at 4:39 PM, Bill Burke <bburke_at_redhat.com
>>> <mailto:bburke_at_redhat.com>> wrote:
>>>
>>>> IMO, no filters should be executed until the resource method is
>>>> matched except for PreMatch filters.
>>>>
>>>> On 9/10/2012 10:09 AM, Sergey Beryozkin wrote:
>>>>> Hi
>>>>>
>>>>> The documentation for ContainerResponseFilter suggests that say
>>>>> name-bound response filters can be executed after a subresource locator
>>>>> method has been invoked.
>>>>>
>>>>> However, the actual response is not even available at that stage, we are
>>>>> still in the process of locating the actual resource method - it is only
>>>>> available after a final resource method has been invoked.
>>>>>
>>>>> I'd like to suggest that the documentation is clarified in that regard.
>>>>>
>>>>> Also, ContainerRequestContext docs probably need to be updated to say
>>>>> that IllegalStateException is to be thrown whenever one of its 'setter'
>>>>> methods is invoked as part of the response filter chain execution
>>>>>
>>>>> Thanks, Sergey
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>
>>
>
>