I have one more query about it.
Global interceptors, those which have no name bindings and are executed
by default at the past-match stage, are they executed
1) per every matched request method (ex, in the case where subresources
are involved)
2) only on the first request method match
3) only after the root resource is selected (but no the initial request
method is matched)
Guess it is 1, but not 100% sure
Thanks, Sergey
On 06/09/12 14:06, Sergey Beryozkin wrote:
> On 06/09/12 13:53, Marek Potociar wrote:
>> That's an obvious bug in wording. The "also" applies to the fact that
>> "in that case the filter will *still* be executed in the post-matching
>> phase, but only..."
>> I understand that the current wording is confusing. We should fix that.
> That clarifies it, thanks
>
> Sergey
>>
>> Marek
>>
>> On Sep 6, 2012, at 11:45 AM, Sergey Beryozkin<sberyozkin_at_talend.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Here is the ContainerRequestFilter documentation fragment:
>>>
>>> "By default, i.e. if no name binding is applied to the filter
>>> implementation class, the filter instance is applied globally,
>>> however only after the incoming request has been matched to a
>>> particular resource by JAX-RS runtime. If there is a @NameBinding
>>> annotation applied to the filter, the filter will *also* be executed
>>> at the post-match request extension point, but only in case the
>>> matched resource or sub-resource method is bound to the same
>>> name-binding annotation."
>>>
>>> Note I highlighted 'also'.
>>>
>>> That means to me that if we have @Logged attached to a given
>>> ContainerRequestFilter and also to some request method, then we get
>>> this request filter executed twice, once after a root resource has
>>> been selected, and once - after the matching request method has been
>>> selected.
>>>
>>> Is it really what we want ?
>>>
>>> I think that if we have a name-bound filter then it should only be
>>> executed whenever a selected resource method has the same name binding.
>>>
>>> Thanks, Sergey
>>