On Mar 21, 2012, at 2:06 PM, Bill Burke wrote:
> On 3/21/12 11:29 AM, Santiago Pericas-Geertsen wrote:
>> Hi Bill,
>>
>> At last, I found some time to look at your proposal. Here are some questions:
>>
>> i) From what I gather, entity interceptor chains can no longer be triggered from a filter (there's no readEntity()). Given that, is there a use case for a filter to update an entity interceptor chain?
>>
>
> I don't think so. Plus, with the current API, I don't think you can modify the entity interceptor chain anyways? Correct?
That's right. So my question was regarding use case coverage given that we don't support that.
>
>> ii) Is the response filter chain executed after a call to abort(Response)? Question applies to server and client.
>>
>
> This requires more thought. Resteasy interceptor framework just aborts without calling the response chain, but I don't know what the right answer is. On the server side, it makes sense to call the response chain, but I'm not so sure on the client.
I agree it seems less useful on the client. OTOH, symmetric semantics is always a good thing IMO.
>> iv) The RequestFilterContext has a few methods that only seem to apply to pre-match filters. Presumably, these will throw some sort of exception otherwise. Wouldn't be in the philosophy of this new approach to split these contexts?
>>
>
> Yup a specific PreMatchFilter/Context might be a better/cleaner approach.
>
> All and all, my proposal probably needs some polishing, but the idea is to have specific contracts at each interception point.
Understood.
-- Santiago