On 14/09/12 13:54, Bill Burke wrote:
>
>
> On 9/14/2012 5:07 AM, 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.
>>
>
> You think its a burden, but its just good application design.
> Filters/interceptors are an advanced feature.
I'm not thinking it's a burden in many cases. I also see it as a pretty
basic feature in many cases, except for a caching example :-), in which
case the users have the mechanism to make it right
>
>> 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.
>>
>
> What will I tell the user? Either specify a @BindingPrioirty, or
> register the filter/interceptor with a binding priority. Its the right
> thing to do. Its pretty hard for an interceptor implementation to
> automatically figure out which order the user wants without metadata.
> While you may feel global filters should be run first, other users may
> feel differently.
>
Sure. The question is about introducing a predictability in cases where
the binding priority is missing (default), I feel that there's some
implicit distinction between filters which are supposed to be applied to
all methods as opposed to those which are meant to be applied to the
selected few.
By the way, I'm not pushing for the resolution any longer, thought I'd
clarify my position given your comments
Cheers, Sergey
>> 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.
>>
>
> which cases are those specifically? I'm sure these global filters you
> are talking about fit into a specific category.
>
>
>> 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.
>>
>
> IMO, if you really want to do this in CXF, you're better off defining
> configuration for different default binding priorities for your global
> and name-bound filters/interceptors.
>
>