On 5/15/12 1:05 AM, Santiago Pericas-Geertsen wrote:
> On May 14, 2012, at 12:05 PM, Martin Matula wrote:
>
>> My thoughts:
>> - for things that make the stream readable by others (i.e. deal with encoding), interceptors will always be global (because it is the sender who decides how the stream is encoded and indicates so in the header - for that reason the decoding interceptors will typically be global and depending on the header info - it does not make any sense to make these name-bound).
>> - interceptors that intercept incoming messages which are name bound, are typically not essential for reading the stream - they are specific to how the method annotated by the given annotation wants to pre-process the stream (i.e. they have not much to do with how the sender encoded the message, but more with how the receiving method wants to read it)
> I think this is generally true, but I could also come up with exceptions to these rules …
>
>> For that reason, I don't think readEntity() in pre-matching filter not invoking the name-bound interceptors is an issue
> This was not the issue that prompted the proposal to drop it from a pre-matching filter. The issue is (i) the overall complexity of a model in which interceptor chains are different in pre and post filters (more for the developer to understand) and (ii) the apparent mismatch of having to pass an Annotation[] in a pre-match context.
>
>> Also, I am not sure readEntity() has to take any annotations.
> That's one of the points of the proposal.
>
>> What about dynamically bound interceptors?
> I don't see the issue. Could you elaborate? Dynamically bound interceptors are resolved at deploy time.
>
>> IMO annotations parameter should be removed from readEntity() - interceptors chain should be built by the JAX-RS runtime based on the current context - if it is in the pre-matching phase, no name-bound or dynamically bound interceptors are relevant, so only global ones would be used. If the context, already has info about the matched method, the right dynamically bound as well as name-bound interceptors should be in the chain.
> That would mean the corresponding MBR will always get an empty array of annotations? Aren't we restricting its functionality by doing that? Again, I think the reason why we're going in this direction is because we are allowing readEntity in the pre-match phase. IMO, interceptors (as wrappers over MBR/MBW that deal with annotations from declarations) are really post-matching thingies ...
I disagree. To me the main use-case for the interceptors on the
receiving end is acting based on the headers (as I said multiple times).
It is the responding side where annotations are interesting for
interceptors, not the receiving side. That's my personal view.
If that's too complicated to accept/agree on, you can remove the
readEntity() and bufferEntity() from the API completely - that lets
implementations (such as Jersey) provide a proprietary API to workaround
that and define whatever semantics they like for their impl without
having to reach a collective agreement. Once more experience is gained
and if it proves to be useful, it can always be added to a later
revision of the spec.
Martin