Santiago, would you like me to create a JIRA to keep this issue tracked ?
I've just checked the latest spec source, no change has been applied
there
thanks, Sergey
On 27/11/12 10:41, Sergey Beryozkin wrote:
> Hi Santiago
>
> On 26/11/12 15:45, Santiago Pericas-Geertsen wrote:
>>
>> On Nov 23, 2012, at 6:17 AM, Sergey Beryozkin<sberyozkin_at_talend.com>
>> wrote:
>>
>>> On 20/11/12 14:04, Bill Burke wrote:
>>>>
>>>>
>>>> On 11/20/2012 5:42 AM, Sergey Beryozkin wrote:
>>>>> 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...
>>>>>
>>>>
>>>> In Resteasy, we allow you to write a mapper for any exception class, so
>>>> I vote #2.
>>>
>>> Me too. I've thought about it more, I can see why the case for the
>>> optimization might work, however the case of supporting the WAE
>>> mappers seeing all WAEs for the purpose of not necessarily converting
>>> them to Responses but its own statistics/logging/etc purposes is
>>> stronger IMHO.
>>>
>>> It will indeed technically break the BC but at the expectation level
>>> only - the risk though seems pretty minimal and would affect only
>>> mappers not doing proper checks on WAE Response...
>>>
>>> It can be recommended at the spec level to get custom WAE mappers to
>>> check that Response entity is not null before trying to do its custom
>>> conversion if any.
>>>
>>> Furthermore, I'm assuming this 'expectation' issue can be handled at
>>> the RI level only by introducing a Jersey specific property that can
>>> be enabled to get the optimization still supported in cases where
>>> someone has indeed written a mapper which does immediate conversion
>>> without any checks...
>>
>> Although I have some concerns about BC, I can see the value of the
>> proposed change. I gather from this discussion that Resteasy and CFX
>> already do what's being proposed. Can you confirm?
>
> Yes, in CXF a WAE mapper will be able to see all WAE exceptions
>
> Cheers, Sergey
>
>>
>> -- Santiago
>
>