On Aug 23, 2012, at 8:23 AM, Marek Potociar wrote:
>
> On Aug 22, 2012, at 9:22 PM, Santiago Pericas-Geertsen <santiago.pericasgeertsen_at_Oracle.com> wrote:
>
>>
>> On Aug 22, 2012, at 11:59 AM, Bill Burke wrote:
>>
>>> Maybe this might simplify things?
>>>
>>> If exception thrown from resource method
>>> - ExceptioMapper
>>> - response filters and interception if there is an entity.
>>>
>>> If an exception thrown in response filter (or WriterInterceptor)
>>> - ExceptionMapper
>>> - no additional filtering or interception.
>>
>> How about this variation? Exception in:
>>
>> (1) Pre-match request filter or Response filter or Writer Interceptor
>> -> Exception Mapper -> Response
>>
>> (2) Post-match request filter or Resource method or Reader interceptor
>> -> Exception Mapper -> Response chain -> Response
>
> Why is reader interceptor different?
Than the writer interceptor? A writer interceptor will be called after the response chain, if it throws an exception, it seems unnecessary to do the response chain again.
>
>> Notes:
>>
>> - If abortWith(Response) called in pre-match then (1)
>
> Why should abortWith(Response) be treated differently for this case? FWIW, in Jersey we have not seen ANY use case where a response filter would require resource information. I'm not saying there are no such use cases. Yet from our experience response filters deal almost exclusively with response headers or entity. So I'd say that global response filters should be applied to abort response in all cases.
>
>>
>> - If abortWith(Response) called in post-match then (2)
I propose to treat abortWith() just like producing a response from a mapped exception. So it follows the rules for (1) and (2) depending on where it is called.
>>
>> - Writer interceptors executed after Exception Mapper
>
> So if executed BEFORE any exception mapping, the exception thrown from a writer interceptor and mapped to a response would still be filtered?
No, because it falls into case (1) above.
>>
>> - At most one Exception Mapper can be used per request/response (no loops)
>
> What does that mean? E.g. in case (2), what if the second exception is thrown in the response chain? Wouldn't it get mapped to a response?
This means an exception thrown while processing a _mapped_ response is not mapped again (it's propagated to the container).
>>
>> - No such thing as pre-match response filter
>
> For the reasons explained above I'd more agree with a concept of no such thing as "post-matching" global response filters. IOW, global response filters should be invoked for any response regardless of whether the request has been matched or not.
>
> To clarify: by global I mean not name-bound and not dynamically bound. (From previous Jersey experience I would apply the same to request filters too - see my reasoning in my reply to Bill's email.)
OK, let me read the other e-mail to get more context on this.
-- Santiago