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?
-- Santiago