Jan,
> Suppose I have filters
>
> Fa with AUTHENTICATION
> Fb with AUTHORIZATION
> Fc with USER
>
> and reader interceptors
>
> Ia with AUTHENTICATION
> Ib with USER
>
> the order in which these will be invoked is
>
> Fa,Fb,Fc,Ia,Ib
>
> correct?
>
> Is it really desired that interceptors with an earlier binding priority
> (e.g. AUTHENTICATION) are called after the filters with later binding
> priorities?
>
> Obviously the reader interceptors have to be called after the filters,
> but to me the ordering feels strange.
>
> Should the container issue a warning if something like this is
> detected?
>
> Is the developer responsible? Can he be, e.g. if interceptos and
> filters are provided by a 3rd party lib?
>
>
> Again, my goal here is to be able to provide compelling answers to
> similar questions.
It is a technical constraint that interceptors are executed after filters.
The question is whether it makes sense to have an authentication level
*entity* interceptor (which is up to be decided by the programmer that
produces such)? For me it doesn't but possibly for somebody else it does.
The responsibility lies at the person that is setting the @BindingPriority.
If the programmer wants to get that, well, then he gets that. So I do not
see a need that the container should provide a warning, because all
container output is in the end given to all administrators -- which not
necessarily are the programmers of the filters and panic.
I think a real answer can only be provided by someone that can explain why
he *needs* an entity interceptor at all, which I still have not understood,
as I can do everything I need with filters. But I am confident that the spec
leads soon will provide the killer use case to convince us. :-)
Regards
Markus