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

From: Marek Potociar <>
Date: Fri, 11 May 2012 13:31:16 +0200

On May 10, 2012, at 10:37 PM, Bill Burke wrote:

> 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?

It is just explicit statement of the implications, I just wanted to make sure we all see it the same way.

> Then again, is buffered data considered "inbound"?

In our context yes. Also any stream set in an inbound filter context (container request / client response) is 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.

Ok. I thought this would be a hard one. :)
I could say that in Jersey we don't have any interceptors and still are able to cover all the features. But I'm not sure I want to argue about this one over and over again. So I'll just give up on this one. If others don't object then we can focus on resolving #2 and we'll be ready to release the next EDR.

>> 2. in pre-matching filters the readEntity() creates and invokes
>> interceptor chain based on (any?) annotations passed to the method
> +1.
>> * still not sure here what is the proposed mechanism / API to
>> allow the interceptor chain assembly
> Not sure what you mean.

How do I assembly the interceptor chain (using JAX-RS API) based on the annotations passed into the readEntity(...) method?

Or do you mean that in pre-matching phase I would take all the global interceptors, add them into chain and let them decide based on the annotations and other data exposed via context what to do and then in post-matching phase I'd add the bound interceptors to the chain and again let the interceptors decide what to do based on the annotations and other data exposed via context?


>> 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