[jax-rs-spec users] [jsr339-experts] Re: Fwd: Re: Re: Re: Re: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors

From: Marek Potociar <>
Date: Thu, 17 May 2012 17:10:16 +0200

All right,

I haven't heard any more comments, so if no-one objects, I am going to remove the readEntity and bufferEntity from inbound filter contexts completely tomorrow and release the next non-snapshot milestone build as a basis for EDR 3.


On May 15, 2012, at 8:22 PM, Marek Potociar wrote:

> FYI.
> Begin forwarded message:
>> From: Martin Matula <>
>> Subject: [jax-rs-spec users] Re: [jsr339-experts] Re: Re: Re: Re: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors
>> Date: May 15, 2012 5:30:21 PM GMT+02:00
>> To:
>> Cc: Santiago Pericas-Geertsen <>, Marek Potociar <>, Sergey Beryozkin <>,
>> Reply-To:
>> On 5/15/12 3:36 PM, Santiago Pericas-Geertsen wrote:
>>> On May 15, 2012, at 7:25 AM, Martin Matula wrote:
>>>>>> 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).
>>> I don't disagree with this. It is the main use case. But the fact remains, MBR can get information from the annotations as per JAX-RS 1.X. Because they can, there are likely some implementations out there that do. Any resource representation (data format) that isn't self contained _may_ take advantage of this.
>>> Examples of formats that are _not_ self contained are EXI in schema mode and ASN.1 with an encoding like PER. In either case, external information (not contained in the request) are needed to decode a message --namely a schema/type definition. This information _could_ be provided via annotations. These cases are likely rare in the REST world, but not necessarily impossible.
>> If the pre-matching filter needs to read the entity, it knows what it wants to read (similarly to the resource method knowing what it is capable of reading) - i.e. it would only be interested in the entity if it is of a given type (e.g. www-form-urlencoded). Otherwise it knows it cannot read it and isn't interested. I am quite confident nobody is going to expect, that if they write a filter that tries to always read entity as Form.class (regardless of the content type), it will work.
>> Also, as I said in the previous e-mail, I am guessing in some cases I actually don't want my filter to apply the method annotations and dynamically bound interceptors even in the post-matching phase. The filter may want to read it in it's own way not necessarily related to the way how the target resource method reads it.
>>>> 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.
>>> We've come a long way, let's not give up :) Could we revisit the use case of the form parameter that needs to be process during pre-match? Are you convinced that it is an essential use case to support?
>> It is not giving up. Dropping readEntity() is a valid result. The discussion was useful if it leads to realizing that it may be premature to include readEntity() in the official API, as it seems there is not enough experience with that. Better to not include something than realizing later it was a mistake. It is easy to add/adjust/remove a proprietary API, but once we add it to the JAX-RS, we have to stick with it "forever".
>> I don't think the method override by the form parameter is essential. On the other hand I think I am more comfortable with removing the readEntity() method completely than keeping it in with the proposed semantics (of applying all interceptors in the post matching phase and throwing exception in the pre-matching phase). I think we need more experience to see what really makes sense.
>> Martin