Hi Santiago
I'm sorry, it is all the filters that I'm 'after' at the moment, I
referred to 'interceptors' by mistake
Cheers, Sergey
On 10/09/12 14:35, Santiago Pericas-Geertsen wrote:
> Hi Sergey,
>
>> Global interceptors, those which have no name bindings and are executed by default at the past-match stage, are they executed
>
> Interceptors are all post-matching because filters can only operate at the "stream" level now.
>
>>
>> 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)
>
> I'm not sure I understand these cases. In the latest proposal, a reader interceptor will intercept the call to the MBR and will be executed once (at most once) after all the request filters; a writer interceptor will intercept the call to the MBW and will be executed once after all the response filters.
>
> Just like post-match filters, global interceptors and name-bound interceptors should be sorted by priority on the same processing chain: the reader or the writer chain.
>
> -- Santiago
>
>> 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
>>>>
>>
>>
>