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

From: Sergey Beryozkin <>
Date: Thu, 13 Dec 2012 10:10:47 +0000

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

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