users@jax-rs-spec.java.net

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

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Sun, 13 May 2012 17:00:45 +0100

Hi
On 11/05/12 17:09, Bill Burke wrote:
>
>
> 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.

One other question is whether filters can get the contexts injected or
not. ContainerRequestContext has accessors for UriInfo, etc, so I'm
assuming that the injection is not to be supported. But if it were then

ContainerRequestContext.readEntity() would definitely be redundant,
because that is what the Providers context is for...

I also agree that the use case of overriding the HTTP verb using form
parameters is not strong enough to keep readEntity(), I guess this is
typically done with HTTP headers...Though it is still might be useful to
readEntity into some custom class and making the filtering decision but
I think ReaderInt or MBR can also manage this scenario


Cheers, Sergey


>
> Bill
>


-- 
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com