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?
> 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.
> iii) What's the benefit of ClientResponse extending Response? Exceptions?
>
Yes. We might have an exception hierarchy that is re-used from client
and server. i.e. WAE is one such exception and it takes a Response as a
parameter.
> 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. I think this is
important because we can control exactly what a user can (and more
importantly) *cannot* do. With the current API, IMO, there's just way
too many weird edge cases you have to code for.
Thanks for checking it out and reviewing my input.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com