users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: response filtering and exceptions

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Tue, 24 Jul 2012 17:05:26 +0200

Well, I guess you could use a custom exception mapper and request-scoped properties to communicate with your filter/interceptor. That might be perhaps a viable solution in case the use case we are looking at is a rather obscure one. So that makes me wonder what is the actual use case to justify the new methods?

Also, if we agree that the methods are useful, perhaps a single exception getter (that may return null if there was no failure) would do the trick? E.g.:

Throwable getFailure();

?

...but I guess I'd really like to learn more about the use case...

Marek

On Jul 24, 2012, at 2:06 PM, Bill Burke wrote:

> Alternatively you could not invoke any ContainerResponseFilter exceptions because we have ExceptionMapper, but WriterInterceptor probably still needs to know if an exception was thrown.
>
> On 7/23/12 1:39 PM, Bill Burke wrote:
>> java.net/jira/browse/JAX_RS_SPEC-230
>>
>> On 7/23/12 12:11 PM, Marek Potociar wrote:
>>> Hi Bill,
>>> Let me have a look. Have you file a Jira issue yet? :) If yes, what's
>>> the number?
>>>
>>> Marek
>>>
>>> On Jul 11, 2012, at 4:28 PM, Bill Burke wrote:
>>>
>>>> Hi all,
>>>>
>>>> I think we need something in ContainerResponseFilter to distinguish
>>>> that an exception was thrown from application code (and maybe
>>>> internally as well). Came across a user case recently that wanted to
>>>> know that a failure occured and what exact exception.
>>>>
>>>> I suggest at minimum, 2 methods on ContainerResponseContext (better
>>>> names maybe?). Probably similar methods on WriterInterceptor.
>>>>
>>>>
>>>> boolean wasFailure();
>>>> Throwable getFailure();
>>>>
>>>> Don't know, but maybe also a new method on ContainerResponseFilter
>>>>
>>>> void failure(ContainerRequestContext requestContext,
>>>> ContainerResponseContext responseContext)
>>>> throws IOException;
>>>>
>>>>
>>>> failure should be called after any ExceptionMapper, but before
>>>> anything else.
>>>>
>>>> The main reason for this is name-bound filters and interceptors might
>>>> want to make a different decision based on a user failure.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com