Here is a proposed updated to the ordering algorithm of POST-MATCH filters:
- the filter that has a binding priority set explicitly is preferred to
the one that does not
if both filters have priorities set explicitly:
compare them according to the docs
otherwise:
the global filter is preferred to the name-bound one (aka is chosen
to run first, or the other way around)
That fits Bill's case,
I promise, I won't continue with this thread if people disagree with the
above :-)
Sergey
On 14/09/12 10:07, Sergey Beryozkin wrote:
> 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
>