All right,
One more iteration on the subject: We MUST support response filters that are executed even if a resource has been matched.
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.
Marek
On Sep 10, 2012, at 6:23 PM, Marek Potociar <marek.potociar_at_oracle.com> wrote:
> Fixed,
>
> Marek
>
> On Sep 10, 2012, at 4:39 PM, Bill Burke <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
>