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

From: Bill Burke <>
Date: Thu, 22 Mar 2012 10:38:31 -0400

On 3/21/12 5:07 PM, Marek Potociar wrote:
>> In my experience on the Resteasy side, filters rarely wrap i/o streams. They either add/remove headers or abort/redirect request/responses. What I found that is the i/o stream wrapping happens in MessageBodyReader/Writer interceptors. This is because reading/writing an entity is usually independent of whether this is happening on the client or server while abortion/redirection is specific to its context.
> Ok, makes sense. What I am only trying to point out is that reader/writer interception can be substituted with a filter wrapping the input stream. Arguably, R/W interceptors make it more convenient and suitable for common (client/server) use cases.

I see your point. Either we have less spec interfaces and the user has
to write more code, or, more interfaces and the user has to write less
code. There's trade-off either way...


The client side still has weird response flows (which is solve by
ReaderInterceptor). Specifically, that you can't guarantee the
app-developer will ever read the entity, but you still may want to
intercept the response. An example is a client cache, where a
ResponseFilter will want to cache the bits received from the server
whether or not the app-code decides to read the entity. IMO, this is
not dissimilar from the PreMatch/PostMatch filter.

>> Currently, I just don't see how you could *not* have the general interceptor architecture we currently have based on the requirements I spelled out last year:
>> But, I do think the API has room for improvement.
> I was thinking about a possibility to let filters manipulate reader/writer interceptor chains (add/remove interceptors). Would that make sense to you?

What is the use case for this? Adding/removing interceptors at runtime?
  Isn't it a feature that could be added later on in JAX-RS 2.1?

>> A 3rd disadvantage of the current API is that some methods have different behavior in different contexts.
> I can't recall any.

close(), bufferEntity() to name a couple. A lot of methods have a lot
of fine-print in the Javadoc too (like readEntity()).

Bill Burke
JBoss, a division of Red Hat