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: Marek Potociar <marek.potociar_at_oracle.com>
Date: Thu, 23 Aug 2012 18:38:58 +0200

On Aug 23, 2012, at 5:03 PM, Bill Burke <bburke_at_redhat.com> 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?

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

While I do not see the need, I'm not against having that. But if we don't have a real use case, maybe we could defer adding the method until we find one?

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

Ok, so it seems we may be able to agree on the proposal I sent in my other email[1] (boy, I honestly miss better email hyperlinks now...).

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? (Note that name-bound can be applied to the Application class which would make them global & post-matching by default.) We could get rid of the @PreMatching annotation altogether.

Marek

[1] http://java.net/projects/jax-rs-spec/lists/jsr339-experts/archive/2012-08/message/133
>
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com