[jax-rs-spec users] [jsr339-experts] Re: Re: Re: WebApplicationException Response entity and exception mappers

From: Santiago Pericas-Geertsen <>
Date: Thu, 13 Dec 2012 09:30:37 -0500

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

-- Santiago

On Dec 13, 2012, at 5:10 AM, Sergey Beryozkin <> 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<>
>>> 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