I'll dig on what they wanted, but I think it was that they didn't want
to execute a particular filter/interceptor.
On 7/24/12 11:05 AM, Marek Potociar wrote:
> 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
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com