users@jax-rs-spec.java.net

[jax-rs-spec users] Re: Global post match ContainerRequestFilter and subresources

From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
Date: Wed, 1 Apr 2015 10:05:49 -0400

> On Apr 1, 2015, at 7:14 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>
> Just a quick follow-up,
>
> One (possible) limitation with this policy (a post-match request filter is not applied to subresource locators) is that one can not have a BeanValidation implemented with a request filter, the implementation specific mechanism is required to support the validation of the parameters passed to the sub locators

 I believe our BV integration only applies to the resource method matched (and its resource class). That is, validation is done after matching not during matching which is when locators are called.

— Santiago

>
> On 25/03/15 16:56, Sergey Beryozkin wrote:
>> Hi Marek
>>
>> Thanks, sorry I pasted the info about a double response filtering with
>> clarifying the details with the user.
>>
>> Right, I guess it does make sense to have a request filter skipping the
>> sub-resource locators as we are still in the process of finding the
>> actual/final resource method, a 'resource' target. I misread the
>> documentation initially.
>>
>> Thanks, Sergey
>>
>> On 25/03/15 14:47, Marek Potociar wrote:
>>> Hi Sergey,
>>>
>>> AFAIK, the only use case where response filter is invoked twice in
>>> Jersey is when there’s an exception thrown from a response filter, which
>>> is mapped to a response by an exception mapper and that response is
>>> again passed through the response filter chain (section 6.7.1 of the
>>> spec).
>>>
>>> In general, request response filters should only be invoked _once_ for a
>>> typical use case. Request filters should not be invoked on sub-resource
>>> locators at all.
>>>
>>> Cheers,
>>> Marek
>>>
>>>
>>>> On 25 Mar 2015, at 14:06, Sergey Beryozkin <sberyozkin_at_talend.com
>>>> <mailto:sberyozkin_at_talend.com>> wrote:
>>>>
>>>> The user has reported that his experiments with Jersey have shown that
>>>> in the below case Jersey invokes a global post-match
>>>> ContainerRequestFilter once but ContainerResponseFilter twice.
>>>>
>>>> For the record, CXF invokes ContainerRequestFilter twice and
>>>> ContainerResponseFilter once.
>>>>
>>>> I guess invoking a global ContainerResponseFilter twice in a case
>>>> below is consistent with my reasoning that such a filter has a
>>>> wild-card name-binding.
>>>>
>>>> Should it be (as far as global request response filters are concerned
>>>> in the below example):
>>>>
>>>> ContainerRequestFilter: twice
>>>> ContainerResponseFilter: twice
>>>>
>>>> ?
>>>>
>>>> Cheers, Sergey
>>>>
>>>> On 25/03/15 12:35, Sergey Beryozkin wrote:
>>>>> Hi All
>>>>>
>>>>> I've had a user query and I'm reviewing the documentation at [1] and
>>>>> I'm
>>>>> actually not sure if I understand it completely.
>>>>>
>>>>> Right now, CXF will run the same global post-match
>>>>> ContainerRequestFilter twice with the following service class:
>>>>>
>>>>> @Path("rs")
>>>>> public RSService {
>>>>> @Path("sub")
>>>>> public RSService sub() {
>>>>> return this;
>>>>> }
>>>>> @Path("resource")
>>>>> @GET
>>>>> public Response get() {
>>>>> //
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>> and
>>>>>
>>>>> GET /rs/sub/resource
>>>>>
>>>>> once for the sub() method, and once for the get() method.
>>>>>
>>>>> I vaguely suspect it might be wrong, but the docs at [1] mention that
>>>>> both resource and subresource methods can be invoked when Name Bindings
>>>>> are used and in case of a global filter it is effective a wildcard name
>>>>> binding.
>>>>>
>>>>> Marek, Santiago, can you please be nice (as you always are :-)) and
>>>>> clarify: how many times a global filter is expected to be called in the
>>>>> above case, 1 or 2 ?
>>>>>
>>>>> Thanks, Sergey
>>>>>
>>>>> [1]
>>>>> https://jax-rs-spec.java.net/nonav/2.0-rev-a/apidocs/javax/ws/rs/container/ContainerRequestFilter.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com