http://java.net/jira/browse/JAX_RS_SPEC-318
Cheers, Sergey
On 13/12/12 15:04, Sergey Beryozkin wrote:
> Hi
> On 13/12/12 14:30, Santiago Pericas-Geertsen wrote:
>> Hi Sergey,
>>
>> I should have followed up with you on this one. Although, as I said, I
>> understand where you and others are coming from, the RI (Jersey)
>> implements this logic _exactly_ in the way defined by the spec.
>
> I guess the idea of this optimization came from the Jersey team :-)
>
>>
>> I thought this was another case in which we could make a non-BC change
>> based on what the existing implementations were doing (we've done it
>> before). But it isn't, it is clearly documented in the spec and the
>> RI's source code. Thus, I'm skeptical about pursuing this non-BC change.
>>
>> In any case, if you want to file a JIRA, we can follow up the
>> discussion there.
>
> Let me ask a very specific question:
>
> Do you support
>
> >>>>>>> 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"
>
> ?
>
> Bill - do you accept it too ? I can go for this option too but I don;t
> think simply keeping the text intact is correct
>
> Thanks, Sergey
>
>>
>> -- Santiago
>>
>> On Dec 13, 2012, at 5:10 AM, Sergey Beryozkin<sberyozkin_at_talend.com>
>> wrote:
>>
>>> 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
>>>>
>>>>
>>
>
>