On Sep 12, 2012, at 5:32 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> On 9/12/2012 5:55 AM, 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. *
>>
>> 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.
>>
>
> But...ordering is still important. If there has been a match, name and global are sorted based on BindingPriority and executed together.
Sure, makes sense. That's what I assumed.
Marek
>
> Bill
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com