users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Are name-bound container filters executed twice ?

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Mon, 10 Sep 2012 14:01:14 +0100

Sorry for getting back and forth with my queries, but some
clarifications are do needed IMHO.

No questions regarding pre-match global request filters - I guess we
have to update the docs which should say that say ValidationExcepption
has to be thrown in case of @PreMatching annotation co-existing with
name bound annotations in a given filter class declaration.

The way post-match filters are executed is not quite clear to me.
No questions again for name-bound filters - Marek clarified that.

However, global post-match filters seem to have to be executed per every
match method in the match chain.

For example, consider a global pre-processing filter of some sort.
And lets say we have a resource method annotated with @Logged.

Right now the wording implies that only filters annotated with @Logged
will be executed, but obviously the user would expect the global
non-bound filter be applied too.

I suggest that the docs gets changed to read something along these lines
"Global post-match filters are always executed per every root resource
and subresource locator method match, name-bound filters - is the way to
restrict it, pre-match - is the way to run the filter no matter what"

Cheers, Sergey



On 10/09/12 13:06, Sergey Beryozkin wrote:
> On 07/09/12 20:52, Sergey Beryozkin wrote:
>> 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
>
> The reason I'm asking for this clarification is that if we have a name
> bound sub resource locator method and a global filter, then we have a
> case where it's not exactly known yet if the resource URI can actually
> be matched to the final resource method and yet we have a global filter
>
> Cheers, Sergey
>
>>
>> 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
>>>>
>>
>>
>
>