[jax-rs-spec users] [jsr339-experts] Re: Re: Re: Fwd: [Resteasy-users] PostProcessInterceptors not invoked for responses created by ExceptionMappers

From: Bill Burke <>
Date: Thu, 23 Aug 2012 13:13:25 -0400

On 8/23/2012 12:38 PM, Marek Potociar wrote:
> On Aug 23, 2012, at 5:03 PM, Bill Burke <
> <>> wrote:
>> On 8/23/2012 8:06 AM, Marek Potociar wrote:
>>> Btw. seems to me that dynamically bound global filter that has all
>>> the necessary resource-specific initialization properties (e.g.
>>> ResourceInfo etc.) pre-computed at deploy time will be anyway more
>>> efficient than a global post-matching filter that will need to inject
>>> proxied resource information with every request.
>> Ya, we precompute post match request filters and response filters and
>> reader/writer interceptors at deploy/redeploy time.
> I wonder what do you do for sub-resources? That's something that cannot
> be generally pre-computed, right?

Can't precompute at deploy time, no, but we cache mappings and other
metadata based on class on demand. Otherwise sub-resource invocations
would be really inefficient.

> What about the distinction between pre-post matching request filters? Do
> we need that at all? Can we just have all "unbound" filters pre-matching
> and all name-bound or dynamically-bound post-matching?

I don't think we can do that (remove @PreMach). For example, something
like @RolesAllowed is a name-bound filter and authorization should
really come before as many filters as possible, don't you think?

(Note that
> name-bound can be applied to the Application class which would make them
> global & post-matching by default.)

Can you explain more what you're talking about with Application class?


Bill Burke
JBoss, a division of Red Hat