Hi Sergey,
Even in JAX-RS 1.X, an exception thrown (e.g., in a MBR before the matching resource method is invoked) and mapped to a response by an exception mapper is "processed as if the web resource method had returned the Response" (Section 4.4).
In 2.0, we have tried to preserve this "philosophy" by running the processing pipeline (including filters and interceptors) as if the response had been produced by the resource method.
> "1. If a web resource has been matched before the exception was thrown, then the filters in ContainerResponse and the interceptors in WriteTo will include everything that has been bound to the method as
> well as globally;"
>
> This sounds reasonable to me, the question is should it be reworded such that the method-bound ContainerResponseFilters are applied in case of the exceptions in case 1 only if the matched resource has actually been invoked, as opposed to matched only ?
>
> If PostMatch ContainerRequestFilter throws the exception and the exception mapper maps it to Response with the text entity, then the method bound ContainerResponseContext filters which may be expecting that the response entity class and type equal to say Book.class (as per the return type of the bound resource method) will actually see String.class.
But couldn't this happen also if the resource method is actually called (as you are suggesting) and _it_ throws an exception that is mapped to a response whose entity is not of type Book.class? So changing the rule from matched to invoked does not prevent this, right?
-- Santiago
> On 13/03/13 13:46, Sergey Beryozkin wrote:
>> Hi Santiago,
>> On 13/03/13 13:37, Santiago Pericas-Geertsen wrote:
>>>
>>> On Mar 12, 2013, at 6:40 PM, Sergey Beryozkin<sberyozkin_at_talend.com>
>>> wrote:
>>>
>>>> Hi
>>>>
>>>> I'd like to double-check something,
>>>>
>>>> When MBW throws an exception which gets mapped, the response will be
>>>> routed via the available response filters and/or writers, is that
>>>> correct ?
>>>>
>>>
>>> Yes, see 6.7.
>>
>> Thanks, the reason I asked is that that section actually talks about
>> filters & (writer) interceptors only (assuming the current chain is the
>> outbound one), but does not mention MBW. But indeed, it makes sense that
>> the filters/writers should have the chance to work with the mapped
>> exception even if it originated from MBW
>>
>>> Also note that exceptions are mapped only once during a
>>> request/response processing lifecycle.
>> Yes, Marek clarified that too
>>
>> Thanks, Sergey
>>>
>>> -- Santiago
>>>
>>>> On 04/02/13 12:08, Sergey Beryozkin wrote:
>>>>> On 04/02/13 12:05, Marek Potociar wrote:
>>>>>>
>>>>>> On Feb 4, 2013, at 12:29 PM, Sergey Beryozkin<sberyozkin_at_talend.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On 01/02/13 16:42, Marek Potociar wrote:
>>>>>>>> I see what you mean. Feel free to file a Jira issue so that we can
>>>>>>>> consider it in 2.1 timeframe.
>>>>>>> Sounds good, will do.
>>>>>>>
>>>>>>> By the way, AFAIK, MBW can also throw the exception, and the process
>>>>>>> is similar, if the exception is mapped then feed Response to MBW
>>>>>>> again and if MBW throws it again - propagate to the container.
>>>>>>>
>>>>>>> I'm assuming that the filters throwing exceptions and then processing
>>>>>>> mapped responses does not affect the related MBW process, so
>>>>>>> effectively we can have the exceptions thrown and mapped twice on the
>>>>>>> server response chain, once by filters, next by MBW.
>>>>>>>
>>>>>>> Or, actually, 3 times ?
>>>>>>>
>>>>>>> Filters, then possibly WriterInterceptor and finally - MBW ?
>>>>>>
>>>>>> No, the idea is to only re-map exception once. So, in general, no
>>>>>> matter where the exception comes from, if causes another exception,
>>>>>> the exception will be propagated to container.
>>>>>>
>>>>> OK, makes sense
>>>>>
>>>>> Sergey
>>>>>
>>>>>
>>>>>> Marek
>>>>>>
>>>>>>>
>>>>>>> Thanks, Sergey
>>>>>>>
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Marek
>>>>>>>>
>>>>>>>> On Feb 1, 2013, at 5:24 PM, Sergey Beryozkin<sberyozkin_at_talend.com
>>>>>>>> <mailto:sberyozkin_at_talend.com>> wrote:
>>>>>>>>
>>>>>>>>> Yes, I agree it makes sense in most cases to support it.
>>>>>>>>> I think there could be some issues though like double logging or
>>>>>>>>> similar, etc, when the response filter which throws the
>>>>>>>>> exception has
>>>>>>>>> been prioritized to be after such filters like logging one, etc.
>>>>>>>>> The user might see for example from the in& out loggers:
>>>>>>>>>
>>>>>>>>> Request: a
>>>>>>>>> Response: aResponse
>>>>>>>>> Response: aResponse2 or even aResponse
>>>>>>>>>
>>>>>>>>> May be it is negligible this issue. Perhaps it can make sense to
>>>>>>>>> consider adding an annotation like @NonReentrant or similar
>>>>>>>>> either for
>>>>>>>>> 2.0 or 2.1 if the group agrees it can be warranted. I'm easy either
>>>>>>>>> way
>>>>>>>>>
>>>>>>>>> Cheers. Sergey
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>>
>
>