Skip to main content

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

  • From: Marek Potociar <marek.potociar@...>
  • To: jsr339-experts@...
  • Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: response filtering and exceptions
  • 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



[jsr339-experts] response filtering and exceptions

Bill Burke 07/11/2012

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

Marek Potociar 07/23/2012

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

Bill Burke 07/23/2012

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

Marek Potociar 07/23/2012

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

Bill Burke 07/24/2012

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

Marek Potociar 07/24/2012

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

Bill Burke 07/24/2012

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

Marek Potociar 07/27/2012
 
 
Close
loading
Please Confirm
Close