Hi Santiago, one more question.
The spec says
"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.
I guess the above may be reasonable - the bound response filter can be
written such that it does something only if it recognizes the response
entity type.
What do you think ?
Sergey
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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>
>