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