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

From: Bill Burke <>
Date: Fri, 11 May 2012 10:15:02 -0400

On 5/11/12 7:31 AM, Marek Potociar wrote:
>> 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.

FWIW, interceptors evolved from Resteasy when I was implementing various
features. They didn't exist at the start and only appeared when they
were needed. A side effect was it created some measure of usability.

Now, I don't mind revisiting whether to remove interceptors or not, if
we discuss how the various use cases I presented could be implemented
without them. This is much different than arguing to remove
interceptors because they conflict with some edge case.

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

I guess I don't understand why you need to assemble it? Isn't this an
implementation detail of the JAX-RS provider?

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

I don't know. Maybe for all filters readEntity() applies global
interceptors only and "decides based on the annotations and other data
exposed via context what to do?"

No bound interceptors for readEntity() in filters? Does that make it
simpler? Filters should call bufferEntity() to be safe. Actually, this
should be reflected in the Javadoc of readEntity(), IMO. That
readEntity() consumes the input stream and that to be safe, filter
implementations should call buffer entiy.

Bill Burke
JBoss, a division of Red Hat