Re: Change in installing exception mappers

[Sergey Beryozkin <sb...@gmail.com>]

Spec lead's opinion is that a custom RuntimeException mapper should not 
even be able to catch WAE due to its special status. That was possible 
in CXF before 3.1.2 (due to the fact the default handlers were not 
checked if the matching custom handler was available) but not now and 
the only way to get a custom WAE processing is to have a custom 
WebApplicationMapper.
So all works correctly now in CXF but the property I mentioned is here 
now too in case one needs to maintain the backward compatibility 
(RuntimeException mappers being able to catch WAE)

Cheers, Sergey

On 28/08/15 17:52, Sergey Beryozkin wrote:
> FYI:
> https://issues.apache.org/jira/browse/CXF-6568
> On 28/08/15 11:37, Sergey Beryozkin wrote:
>> Hi Benson
>>
>> I've just nearly committed the code that ensures the default
>> WebApplicationExceptionMapper is never preferred over the custom mappers
>> that can handle WebApplicationException, even if the custom mapper is
>> less specific.
>>
>> However I need to double check, can custom  mappers handle
>> WebApplicationExceptions thrown by the runtime itself to mark the error
>> conditions as required by spec, i.e, can the custom mappers treat an
>> exception like NotFoundException thrown by the runtime when it can not
>> find a resource method matching a given path not with 404 but 400, etc...
>>
>> If I do not get any clarifications then I'll make sure the default
>> mapper is *optionally* made the least specific exception mapper to make
>> sure it can enforce the error conditions as required by the spec OOB.
>> Will keep you up to date
>> Thanks, Sergey
>>
>>
>> On 27/08/15 18:25, Benson Margulies wrote:
>>> The funny part here is that my problem was that I'd accidently
>>> introduced a RuntimeException around the exception I intended to map.
>>>
>>> On Thu, Aug 27, 2015 at 1:17 PM, Sergey Beryozkin
>>> <sb...@gmail.com> wrote:
>>>> Hi Benson, glad to hear CXF JAX-RS is not at fault here :-)
>>>>
>>>> Note the default CXF WebApplicationExceptionMapper is typed by
>>>> WebApplicationException. It will win now against a custom mapper that
>>>> for
>>>> example is typed by RuntimeExeption but is also expecting to catch
>>>> WebApplicationException because WebApplicationException is more
>>>> specific.
>>>>
>>>> However the spec does not require that the runtime ships its own
>>>> default
>>>> WebApplicationException mapper. If needed we can easily make the
>>>> default
>>>> mapper registration optional - I'll probably need to make it optional
>>>> actually to make sure the custom RuntimeException mappers can win if
>>>> really
>>>> needed...Will have a look
>>>>
>>>> Sergey
>>>>
>>>>
>>>>
>>>> On 27/08/15 18:13, Benson Margulies wrote:
>>>>>
>>>>> Thanks. The immediate cause was a stupid mistake of mine, but it's
>>>>> good to know about this.
>>>>>
>>>>> On Thu, Aug 27, 2015 at 12:55 PM, Sergey Beryozkin
>>>>> <sb...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> One thing that did change in CXF 3.1.2 is now documented here:
>>>>>>
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS#JAX-RS-CXF3.1.2ProviderSortingChanges
>>>>>>
>>>>>>
>>>>>>
>>>>>> (just did a minor update to refer to exception mappers too).
>>>>>>
>>>>>> We discussed it at length with Romain but basically up until 3.1.2
>>>>>> CXF
>>>>>> was
>>>>>> not entirely compliant with respect to sorting custom and the default
>>>>>> providers which was highlighted by a number of CXF JIRAs relayed to
>>>>>> 2.0
>>>>>> TCK
>>>>>> tests.
>>>>>>
>>>>>> That mostly affects some wildcard custom MBR or MBW.
>>>>>>
>>>>>> CXF ships a default WebApplicationExceptionMapper only so I've no
>>>>>> idea,
>>>>>> without seeing how your GenericExceptionMapper is implemented why
>>>>>> you you
>>>>>> are seeing side-effects. I have probably 10 various Generic mapper
>>>>>> variations in tests and it all works. If they did not catch something
>>>>>> then
>>>>>> well we need to fix it, right ?
>>>>>>
>>>>>> Can you paste the GenericExceptionMapper signature here ?
>>>>>>
>>>>>> And what was the other old code that stopped working, can you
>>>>>> remind me
>>>>>> please ?
>>>>>>
>>>>>> Sergey
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 27/08/15 17:21, Benson Margulies wrote:
>>>>>>>
>>>>>>>
>>>>>>> This is another example of code that worked fine in an older version
>>>>>>> and changes in behavior in 3.1.2.
>>>>>>>
>>>>>>> On Thu, Aug 27, 2015 at 12:00 PM, Benson Margulies
>>>>>>> <be...@basistech.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Has the process of installing an exception mapper changed? My
>>>>>>>> mappers
>>>>>>>> aren't being invoked.
>>>>>>>>
>>>>>>>> sf.setProvider(new
>>>>>>>> JacksonJaxbJsonProvider(JsonUtils.getObjectMapper(),
>>>>>>>>            JacksonJaxbJsonProvider.DEFAULT_ANNOTATIONS));
>>>>>>>> sf.setProvider(new JsonExceptionMapper());
>>>>>>>> sf.setProvider(new WebApplicationExceptionMapper());
>>>>>>>> sf.setProvider(new GenericExceptionMapper());
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Sergey Beryozkin
>>>>
>>>> Talend Community Coders
>>>> http://coders.talend.com/
>>
>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/