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.
> 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.
> 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!!!
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com