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