Let me summarize.
One one hand the spec provides for the optimization in cases where WAE
Response entity is not null. On the other hand, this optimization leads
to the issue where an application code reports WAE with Response having
an entity and also with the cause exception for the benefit of the WAE
mapper.
I'd like to propose one of the following:
1. Keep the current optimization in place but update the spec to say
that "if WAE Response entity is null or WAE cause exception is not null
- use the mapper, otherwise - use WAE Response entity directly"
2. Drop the optimization - I'd expect any custom mapper check WAE
Response anyway before creating some custom Response instead and
dropping this optimization would require a mapper to check if entity is
not null - guess most of the mappers do it all the time anyway...
Will I open a JIRA request ?
Thanks, Sergey
On 16/11/12 23:05, Sergey Beryozkin wrote:
> On 16/11/12 21:32, Santiago Pericas-Geertsen wrote:
>>
>> On Nov 13, 2012, at 12:25 PM, Sergey Beryozkin<sberyozkin_at_talend.com>
>> wrote:
>>
>>> Hi,
>>>
>>> CXF user has pointed out that the specification requires that WAE
>>> exception mapper is not to be used to map a given WAE to Response if
>>> WAE Response entity is not null.
>>
>> Yes, that's according to 3.3.4 and has been like that since 1.X.
>>
>>>
>>> Is it what Jersey and RestEasy do ?
>>
>> I'll check on Jersey and get back to you --I assume that's what Jersey
>> does.
>>
>>> CXF lets custom WAE mappers manage all WAEs, though of course the
>>> custom mapper may choose to somehow modify the original WAE Response
>>> entity if any.
>>>
>>> I'd rather prefer the mappers see all WAEe (and say NotFoundException
>>> mappers see all the NFE exceptions, whether or not NFE Response
>>> entity is null), example, to make sure all WAE isntances can be given
>>> some common treatment like logging them, etc.
>>
>> If there's a response with an entity, I'm assuming the rationale was
>> that there was no need for mapping.
>
> What is about the WAE (and subclass) constructors accepting 'Response &
> Throwable' ? What is going to happen to this 'Throwable' - the mapper
> whose job do something on WAE causes won't be invoked and the cause
> won't be handled
>
> Sergey
>
>> Changing this behavior would not be backward compatible. Let me get
>> back to you on this one.
>>
>> -- Santiago
>>
>