On 5/11/12 11:58 AM, Santiago Pericas-Geertsen wrote:
>
> On May 11, 2012, at 10:15 AM, Bill Burke wrote:
>
>>> Or do you mean that in pre-matching phase I would take all the global
>>> interceptors, add them into chain and let them decide based on the
>>> annotations and other data exposed via context what to do
>>
>> yes
>>
>>
>>> and then in post-matching phase I'd add the bound interceptors to the
>>> chain and again let the interceptors decide what to do based on the
>>> annotations and other data exposed via context?
>>
>>
>> I don't know. Maybe for all filters readEntity() applies global
>> interceptors only and "decides based on the annotations and other data
>> exposed via context what to do?"
>>
>> No bound interceptors for readEntity() in filters? Does that make it
>> simpler? Filters should call bufferEntity() to be safe. Actually, this
>> should be reflected in the Javadoc of readEntity(), IMO. That
>> readEntity() consumes the input stream and that to be safe, filter
>> implementations should call buffer entiy.
>
> The fact that we need to restrict the interceptor chain to only run the
> global interceptors in a pre-match filter makes me think that there's
> still something that is not quite right with the design.
>
> Personally, I think of pre-match filters as the exception (as a way to
> impact the matching algorithm itself) and post-match filters as the
> rule. What if readEntity() is only allowed in post-match filters and
> throws an illegal state exception in a pre-match filter? In a post-match
> filter we have annotations and we can run all the interceptors without
> any special rules. It seems to make more sense in that case.
>
Well, again you have Martin's case of a form-parameter specifying the
HTTP method to invoke. Since the HTTP method is part of matching, I
don't see how you can get around this.
BTW, this use case is very weird anyways. I know you can't use a header
to override the HTTP method for browser-based applications, but wouldn't
it be better to use a query param? That way you have one simple way to
override the HTTP method that works with all media types instead of just
working only with forms.
So, if Martin can agree that this is a bad way of doing HTTP method
overrides, then lets remove readEntity() from PreMatch.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com