[jax-rs-spec users] [jsr339-experts] Re: Re: Review of new Filter API

From: Bill Burke <>
Date: Wed, 11 Apr 2012 13:31:11 -0400

On 4/11/12 8:04 AM, Marek Potociar wrote:
> So even though there would be a FilterableClientResponse, the client request filter would not be able to produce one?
>> Or maybe I'm just not understanding your concern? I don't care that much, just trying to see if things can be cleaned up more.
> Firstly, we should design filters to either work with contexts or messages. So if we are to make the changes on the response side, we should also make the same changes on the request side (ContainerRequest extends Request).
> And then, the conceptual difference between working with a context as opposed to working with a message in a filter is that you may only update the context, but you may completely replace the message. So message-based filter interfaces would need to look like:
> public Message filter(Message); // allows complete replacement or wrapping of the message

Too much like Servlet filters which are really hard to work with. This
either requires a builder API, which is awkward to use, or for you to
wrap a message (like servlet filters) which is a huge pain to do simple
things (like override the input/output stream).

> as opposed to context based:
> public void filter(Context); // context cannot be replaced or wrapped
> In such case we would also need to agree on what gets injected into the resource as a Request instance - I'd say it would have to be the last instance returned by the request filter chain.

Or a third approach, where you have completely mutable request and
response interfaces. Which is something I advocated months ago.

> Note that I am not strictly against the above. The one disadvantage I can see as an API designer is that once we take this approach we will not be able to update the involved message interfaces anymore.

You're saying if we do the Message filter(Message) approach, we may be
screwed in the future if we need to add something that is non-message
based? I see your point. Ok, i'm fine ditching this idea.

Bill Burke
JBoss, a division of Red Hat