users@jax-rs-spec.java.net

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

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Wed, 1 Apr 2015 12:14:01 +0100

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

Cheers, Sergey

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