On 9/13/2012 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.
>
Well, the ordering is pretty important and its something that should be
thought through before deploying an filter or interceptor. Catagories
are given in the BindingPriority annotation. Many times you have
name-bound filters/interceptors that need to be executed before global
ones. i.e. @RolesAllowed Auth filter needs to come before a global
server cache (I have this case in Resteasy).
> As of now, my understanding is the spec/api docs have nothing to say on
> this case. I think it would make sense. If you don't I'm fine with that
> either as I will know what to do with it in CXF.
>
>
> Cheers, Sergey
>
> P.S As a side note, I do not quite like that the auto-discovery mode of
> finding the providers (=> we have BindingPriority, ConstrainedTo)
> affecting the spec and API. I think BindingPriority is there to
> facilitate the case of the runtime 'blindly' picking up the providers
> from the classpath, that is OK, but something is not quite perfect in
> the the implicit link between the auto-discovery and the way all filters
> are ordered.
>
BindingPriority should be used when you are worried about ordering.
Plain and simple as that.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com