users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Re: Re: ContainerResponseFilters must not be executed on subresource locator methods

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Wed, 12 Sep 2012 19:44:20 +0200

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