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

From: Bill Burke <>
Date: Fri, 27 Apr 2012 15:52:38 -0400

On 4/27/12 2:11 PM, Martin Matula wrote:
> Hi Bill,
> I think you convinced me. So, basically, if things stay the way they are, we can be sure all the use-cases are covered. Will have to be careful writing the filters (as it is possible especially for the pre-matching filters that read/writeEntity does not make much sense) and interceptors to ensure they can be reasonably combined. And you are saying you haven't run into the sort of clashes Marek outlined with RestEasy over the last few years you have been using interceptors. So as long as we do a reasonable job in implementing the types of features you mention below the right way and our users combine them in sensible ways, things will work.

Resteasy does not have a PreProcessor interceptor that reads the entity.
  You guys have a valid strong use case that does. It is a valid issue
that we should talk about and work through to see what constraints we
should add to the API or to see if we can get an improved API.

I freaked out because I thought you were really serious about removing
interceptors. Maybe start over and discuss again?

I think:

a) Removing generics might be a good idea. I've never used them. Have
you guys? Then again, what if it could be used as a deployment check?
If an typed interceptor is assigned to a resource method with
non-matching types, it could be flagged at deployment time

b) We should investigate the behavior of calling write/readEntity within
a filter.

c) Maybe writeEntity within PreProcessing should create its own
interceptor chain based on the type and annotation[] array passed into it?

d) Maybe readEntity() should automatically buffer the request?

e) Maybe methods on ContainerRequestContext should be added like
wasBuffered(), wasRead() etc., then other interceptors will know that a
read/write/buffering happened?

Bill Burke
JBoss, a division of Red Hat