jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Ordering of global and name-bound filters

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Fri, 14 Sep 2012 10:07:32 +0100

On 13/09/12 23:15, Bill Burke wrote:
>
>
> On 9/13/2012 5:01 PM, Sergey Beryozkin wrote:
>> On 13/09/12 19:32, Santiago Pericas-Geertsen wrote:
>>>
>>> On Sep 13, 2012, at 12:11 PM, Sergey Beryozkin wrote:
>>>
>>>> On 13/09/12 16:52, Santiago Pericas-Geertsen wrote:
>>>>>
>>>>> On Sep 13, 2012, at 10:49 AM, Sergey Beryozkin wrote:
>>>>>
>>>>>>> Especially when we have different methods having their own
>>>>>>> name-bound
>>>>>>> filters, with some of the name-bound filters mixed up between
>>>>>>> different
>>>>>>> methods. It can be awkward to ensure say all name-bound ones have
>>>>>>> priority number set up right for an expectation that say global
>>>>>>> filters
>>>>>>> will run before or after name bound ones
>>>>>>
>>>>>> PreMatch global filters are having a higher priority over Post-Match
>>>>>> and name-bound filters
>>>>>
>>>>> Is not that they have higher priority, is that they are part of a
>>>>> _separate_ filter chain. Within that chain, they are still sorted by
>>>>> priority. Please check the spec on that. I'm also adding some diagrams
>>>>> in an appendix to clarify this processing pipeline.
>>>>
>>>> OK, thanks.
>>>>
>>>> However, we still have an undefined 'area'. As I noted in the earlier
>>>> email, when I have 3+ PostMatch interceptors, some of them global,
>>>> some of them name-bound, I'd hate go and add numbers to those
>>>> interceptors in order to get some predictability in the way they be
>>>> selected, this does not seem cool at all.
>>>
>>> The default priority is defined to be USER. If the
>>> filter/interceptor is not annotated with @BindingPriority, then just
>>> assume USER. What's the difficulty in doing that?
>>>
>>
>> I'm a user who has build 5-6 filters. I'd like 2 of them run for all the
>> matched resource methods and I'd like them to run before other filters,
>> 3-4 for the selected ones only, I'd like them to run after the global
>> filters if any.
>>
>
> I also have written a lot of filters and interceptors. (I've also done a
> lot of aspect oriented programming.) Ordering is very important and to
> just blindly throw filters/interceptors into a deployment and hope it
> works is just naive.
>
I'm not running this thread to doubt your AOP experience, I'm running it
because I have a doubt and I believe the way to talk about is to offer a
discussion at this list

>> The idea of me going and adding numbers in order to introduce the
>> predictability makes me wonder there's something wrong with the whole
>> idea. In CXF we are going to make name-bound interceptors selected first
>> in such cases always if a given contextual property is enabled - that
>> will be the spec compliant approach because the spec has nothing to say
>> re the ordering of the global & name-bound interceptors with the default
>> priority.
>>
>
> IMO Sergey, this is a naive approach prone to a lot of unforseen errors
> for no good reason. But that's your implementation...
>
> BindingPriority has a suggested list of catagories which make A LOT more
> sense than the implicit rules you are imposing on CXF. It is much better
> for users to think which category their filter or interceptor fits in
> and set the BindingPriority approprietly.
>
>> I was trying to offer a perspective of a user, at least the way I see it
>>
>> You mentioned we effectively have 2 chains, one is pre-match, 2nd one -
>> post match one. My recommendation is two get a post-match chain split
>> into 2 ones, post-match global & post-match name-bound one.
>
> Negative. Again the use case is:
>
> name-bound Auth using @RolesAllowed needs to come before a global
> Server-side cache filter.

OK.

>
>
>> This will
>> make it simpler for users to manage the filters, they will know that
>> global filters will always run before name-bound ones and they do not
>> have to mess with the numbers, but still do that when some more ordering
>> is needed
>>
>
> It will not make it simpler. USers should think about ordering and how
> their filter affects the request or response and apply the appropriate
> BindingPriority category: Authentication, Authorization, Header
> decoration, Encoding. If you are not thinking about ordering, you are
> not designing our filter very well!!!
>
There's an implicit expectation about the ordering, when users (count me
as a user here) think about global vs name-bound filters. In some cases
the ordering may have to be explicitly enabled, example, as in your case
with caching and such.

In other cases this is an extra burden on the user. As a user I want to
have some expectation about when the global filter will run, by default,
compared to name-bound filters.

What RestEasy or Jersey are going to do, when they discover a n-number
of filters all of them with the default priority and then get a user
query why the filters are run in the random order ? The simplest is of
course tell to the user: go and add the BindingPriority annotations.

The idea of me as a user going and adding "2005"/etc priority makes me
sad, in cases when I want a global counter filter run first.

What I've been proposing is to offer some predictability in this 'all
filters have the default priorities' case. In CXF we will offer some
predictability, I don't mind what other implementations do in this regard.


Sergey

-- 
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com