On 17/09/12 16:16, Marek Potociar wrote:
> I think that the proposed changes would make the algorithm unnecessarily complicated (IOW difficult to remember with all the details) and would just lead to raising new set of questions (e.g. is globally bound name-bound filter different from a global un-bound filter in terms of priority? and why?). All that without really bringing in any significant benefits.
>
> So -1 for me.
I accept. For whatever it is worth: in CXF, if binding priority is the
same, the name-binding filter is preferred to a global one. IMHO it's
better than the random selection for same value priorities - the users
will be encouraged to use BindingPriority - but they will know what will
happen if they don't
Cheers, Sergey
>
> Marek
>
> On Sep 14, 2012, at 12:35 PM, Sergey Beryozkin<sberyozkin_at_talend.com> wrote:
>
>> 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
>>>
>>
>>
>