[jax-rs-spec users] [jsr339-experts] Re: Re: HEADS-UP, IMPORTANT: Problems with JAX-RS interceptors

From: Bill Burke <>
Date: Thu, 10 May 2012 16:37:27 -0400

On 5/10/12 3:42 PM, Marek Potociar wrote:
> All,
> thanks for the useful discussion so far. Let me summarize what I see as
> something we can (hopefully) agree upon:
> 1. ContainerRequestFilterContext
> * remove writeEntity()
> * keep readEntity()
> o invokes interceptors
> o does not buffer automatically
> * keep bufferEntity()
> o buffers un-intercepted entity stream
> * keep get/setInputStream()
> o these methods by-pass interceptors
> o invoking setInputStream resets the "buffered flag"
> * additional isRead/Buffered etc. methods might be proved as
> useful, but might be an overkill for now
> o we can add those later if we find out they are really needed

I agree with #1

> 2. Interceptors
> * reader interceptors are invoked on inbound data, writer on
> outbound data only

If writeEntity() is removed, then this point is moot no?

Then again, is buffered data considered "inbound"?

> 3. Other business
> * adding support for a Feature on the server side would be nice
> o needs to distinguish the side either via separate interface
> or annotation
> * @Provider is significant only for the purpose of scanning,
> otherwise it should not be required.
> Let me know if there are any objections to the above.
> Now a few open points:
> 1. interceptors are global only (? not sure if we can all agree on that)

Absolutely not. Annotations triggering interception is really useful
(just see CDI). Resteasy has a number of filters/interceptors triggered
by annotations applied to resource methods.

> 2. in pre-matching filters the readEntity() creates and invokes
> interceptor chain based on (any?) annotations passed to the method


> * still not sure here what is the proposed mechanism / API to
> allow the interceptor chain assembly

Not sure what you mean.

> Let's now try to focus on resolving the open points as well as any
> objections to the closed points.
> As for the open points, I am 50-50 here:
> If we agree on #1 we don't need to solve issues around #2 but we may
> miss some use cases (which I'm still not fully convinced about).
> OTOH, if we choose #2, we would not miss any potential use cases but we
> would most likely make the readEntity() unusable in pre-matching
> filters. Also I don't like the idea forcing people to instantiate
> annotations with #2 - there is no standard way how to do it which
> potentially breaks the portability of the code.

While there are ways to instantiate annotations, a name-bound
interceptor could have access to the resource-method's annotation[] array.

Bill Burke
JBoss, a division of Red Hat