On May 11, 2012, at 10:15 AM, Bill Burke wrote:
>> Or do you mean that in pre-matching phase I would take all the global interceptors, add them into chain and let them decide based on the annotations and other data exposed via context what to do
>
> yes
>
>
>> and then in post-matching phase I'd add the bound interceptors to the chain and again let the interceptors decide what to do based on the annotations and other data exposed via context?
>
>
> I don't know. Maybe for all filters readEntity() applies global interceptors only and "decides based on the annotations and other data exposed via context what to do?"
>
> No bound interceptors for readEntity() in filters? Does that make it simpler? Filters should call bufferEntity() to be safe. Actually, this should be reflected in the Javadoc of readEntity(), IMO. That readEntity() consumes the input stream and that to be safe, filter implementations should call buffer entiy.
The fact that we need to restrict the interceptor chain to only run the global interceptors in a pre-match filter makes me think that there's still something that is not quite right with the design.
Personally, I think of pre-match filters as the exception (as a way to impact the matching algorithm itself) and post-match filters as the rule. What if readEntity() is only allowed in post-match filters and throws an illegal state exception in a pre-match filter? In a post-match filter we have annotations and we can run all the interceptors without any special rules. It seems to make more sense in that case.
-- Santiago