[jax-rs-spec users] [jsr339-experts] Re: Consistency and awkwardness issues with Request/Response/Filter API

From: Bill Burke <>
Date: Wed, 21 Mar 2012 14:06:40 -0400

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

> 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 Burke
JBoss, a division of Red Hat