Maybe - as another way how to satisfy the user requirement - we could also consider providing a an class-level annotation that would prevent filters from being executed on responses provided by an exception mapper? (Just a thought.)
Marek
On Jul 24, 2012, at 7:00 PM, Bill Burke <bburke_at_redhat.com> wrote:
> 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