jsr339-experts@jax-rs-spec.java.net

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

From: Bill Burke <bburke_at_redhat.com>
Date: Thu, 23 Aug 2012 11:03:30 -0400

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.

>>>
>>> *Scenarios:*
>>>
>>
>> Do we need a way to tell a filter that an error happened? Maybe different callbacks?
>
> I know this is not the first time you're asking, but I found the use case presented by your user marginal with an existing work-around. If you insist, we can consider adding following method to ContainerResponseContext:
>
> Throwable getError();
>
> It would return the originating error from which the response was derived (if any) or null (if no error happened).
>

Does anybody else think this is needed? I'm suggesting that context
objects have access to thrown exceptions based on intuition, not on an
actual use case.

>>
>> ContainerResponseFilter {
>>
>> filter(...); // if resource method didn't throw exception
>> applicationException(...);
>> filterException(...);
>> writerException(...);
>> }
>
> I'm against. Why would I force my users implement methods they most likely never need? We have not seen a single use case in Jersey or have not received any user request for Jersey filtering framework that would indicate a need to provide such callback functionality.
>

I was just throwing it out there for discussion and not married to

>>
>> Right now we don't have anything like that. We only run response filters if there was a successful method invocation. Nor do we run filters after Exceptionapper.
>
> That's obviously where my proposal (and current Jersey 2 implementation) differs from yours. I think that response filters should be also run AFTER exception mapping (at least in some cases).
>

Yup. Resteasy does it wrong which is why I wanted to bring this up in
the first place. :) Users seem to need filtering after ExceptionMapper.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com