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

From: Bill Burke <>
Date: Thu, 17 May 2012 11:13:29 -0400

Unrelated: Any way you can make the value() of @Path optional so we can
start prototyping CoC based on discussions we had last year?

On 5/17/12 11:10 AM, Marek Potociar wrote:
> 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.
> Marek
> 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

Bill Burke
JBoss, a division of Red Hat