On May 11, 2012, at 5:43 PM, Bill Burke wrote:
>
>
> On 5/11/12 11:15 AM, Marek Potociar wrote:
>>> Now, I don't mind revisiting whether to remove interceptors or not, if
>>> we discuss how the various use cases I presented could be implemented
>>> without them. This is much different than arguing to remove
>>> interceptors because they conflict with some edge case.
>>
>> All right - but you asked for it :)
>>
>> Note that I am not questioning interceptors as such here. I am merely
>> questioning the need for *name-bound* interceptors.
>
> Ah ok. That may be true (can't think of a case now), but here's some things to think about:
>
> * Interceptors may be interested in annotation metadata to fine-tune their behavior. Name-bound interceptors allow the interceptor to pre-process and cache this metadata.
> * Without name-bound interceptors, a global interceptor that is triggered by an annotation has to check with each read/write whether or not it is enabled.
> * Without name-bound itnerceptors, every possible interceptor has to be in the call stack. Maybe not such a big deal for performance, but really sucks for stack traces!
You are right about the ability of name-bound or dynamically bound interceptors to do some deploy-time preprocessing. We should try not to loose this useful performance optimization.
After reading Martin's comments I'm more inclined to keep the readEntity available in pre-matching as well as post-matching filters. Also it seems useful to have an overloaded version of the readEntity that takes a flag what set of interceptors should be run (global only vs. all). This flag would not have any effect in pre-matching filters. I also think that we should have a convenience version of the readEntity method that does not take the annotations. But we should still keep the version that takes annotation array as an argument to preserve the ability of filters to provide additional metadata to message body reader/writer and/or interceptors.
Would that resolve the outstanding issue?
Marek
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com