[jsr339-experts] Re: [jax-rs-spec users] Re: WebApplicationException Response entity and exception mappers
- From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen@...>
- To: jsr339-experts@...
- Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: WebApplicationException Response entity and exception mappers
- Date: Mon, 26 Nov 2012 10:45:00 -0500
On Nov 23, 2012, at 6:17 AM, Sergey Beryozkin <sberyozkin@...> 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
>>> 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?