users@jax-rs-spec.java.net

[jax-rs-spec users] Re: [jsr339-experts] Re: Example 3: Why current ReaderInterceptors are cool.

From: Bill Burke <bburke_at_redhat.com>
Date: Fri, 27 Apr 2012 15:45:57 -0400

On 4/27/12 2:49 PM, Martin Matula wrote:
> Bill,
>
>
> On Apr 27, 2012, at 6:50 PM, Bill Burke wrote:
>
>> On 4/27/12 12:23 PM, Sergey Beryozkin wrote:
>>
>>> I'm not entirely appreciating the original Marek's concerns as I haven't
>>> started implementing, but I think it's worth exploring the possibility
>>> of minimizing the number of handlers. If the current approach of having
>>> both the filters and Reader interceptors wins then I'll be happy with
>>> that too :-)
>>>
>>
>> If somebody can prove to me first that all the examples I've illustrated (in my blog and in email) are implementable using filters only, we should look into it deeply. If proven, this of course should be weighed against the advantage of Interceptor re-use.
>>
>> I just have a hard time with the fact that Marek and Martin are proposing to remove interceptors based on an edge case. An edge case that I do not believe could be solved by removing interceptors.
>
>
> Dropping interceptors was the *second* of the two ideas for discussion - seems you got stuck there. None of our subsequent e-mails insisted or even suggested that we remove them. We were just trying to see if we can somehow clean up/clarify the interaction with filters. We do see value in interceptors. Just were not sure the consequences have been thought through and understood. We aren't used to the idea - since we have been able to implement our use-cases exclusively with filters and message body workers so far - and the concerns bubbled up as we have been implementing interceptors in the RI.
> Anyway, as I said in my earlier e-mail, personally, I am convinced now and OK with the current state (modulo making interceptors untyped). Thanks for the examples!

The issues you brought up are valid and we should work through them. I
just wanted to kill the idea of removing interceptors. To give you some
background:

For Resteasy, I started with an EJB @AroundInvoke style, because well,
its simple and a pattern I'm familiar with. I ran into the problem of
async HTTP so had create a pre-post filter style like we had now. Then
when implementing caching, I ran into the case for needing interceptors.
  When I implemented interceptors, I found that you could re-use them
many times.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com