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
>>>
>>
>>
>