syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò <ilgro...@apache.org>
Subject Re: Managing WebApplicationException
Date Thu, 22 Sep 2016 13:17:32 GMT
On 22/09/2016 14:48, Sergey Beryozkin wrote:
> Hi Francesco
>
> Yes, option a) is the simplest - c) is always available if you'd like 
> to start customizing the WAE mapping using a standard JAX-RS mechanism.

FYI I have opened SYNCOPE-949 for going with (a).
Regards.

> On 22/09/16 13:31, Francesco Chicchiriccò wrote:
>> On 22/09/2016 13:31, Sergey Beryozkin wrote:
>>> Hi Francesco,
>>>
>>> Happy to be the good one :-)
>>
>> Of course you are ;-)
>>
>>> Please see comments inline
>>
>> Same for me.
>>
>>> On 22/09/16 12:07, Francesco Chicchiriccò wrote:
>>>> Hi all,
>>>> during a recent chat I had with the good Sergey (on another topic), I
>>>> have found that the JAX-RS's standard WebApplicationException (and 
>>>> child
>>>> exceptions) are handled by CXF, according to the specs, via
>>>> WebApplicationExceptionMapper [1].
>>>>
>>>> Syncope's RestServiceExceptionMapper, however, contains some code 
>>>> [2] to
>>>> manage such exceptions, which is never going to be triggered, at this
>>>> point.
>>>>
>>>> Please consider that this affects both 1.2 and 2.0.
>>>>
>>>> IMO, we should either:
>>>>
>>>>  (a) remove [2] and let CXF do its work according to the specs
>>>>  (b) set the 'default.wae.mapper.least.specific' (which is false by
>>>> default) to delegate WebApplicationException to [2]
>>>>
>>> I've checked the spec archives - indeed Marek was saying that WAE,
>>> being a special type of exception, should not be given to the mappers
>>> which are typed to handle WAE subclasses (in that case it was a
>>> RuntimeException mapper).
>>> CXF needs to have a WAE mapper to meet various JAX-RS exception
>>> situations.
>>> The question is if WAE customization is needed. If no - let CXF do it.
>>> If yes, how a user can customize WAE processing if what CXF provides
>>> OOB does not suit.
>>>
>>> (b) would be one option - it is less JAX-RS and more CXF centric
>>> solution - I added that flag because at some point CXF were always
>>> giving the preference to the user-provided providers - so custom
>>> RuntimeException or Exception mappers were able to catch WAE at some
>>> point of time - but later on, after some TCK JIRA issues I ended up
>>> making the code more spec aligned - this caused some side-effects so I
>>> added the flag to keep the user code which depended on the original
>>> selection of the mappers operating.
>>>
>>> Yes another option is introduced a mapper specifically typed to handle
>>> WAE - so you'd have an Exception mapper to handle all but WAE
>>> exceptions and a dedicated mapper to handle WAE only - example - it
>>> may extend a CXF mapper and customize few things or do a WAE mapping
>>> from scratch
>>
>> Ok, that would be option (c) then.
>>
>> Considering what you say above I would rather go with (a) or (c) - as
>> (b) appears a bit too "custom".
>>
>> Any thoughts?
>> Regards.
>>
>>>> [1] 
>>>> https://github.com/apache/cxf/blob/3.1.x-fixes/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/WebApplicationExceptionMapper.java

>>>>
>>>>
>>>>
>>>> [2] 
>>>> https://github.com/apache/syncope/blob/2_0_X/core/rest-cxf/src/main/java/org/apache/syncope/core/rest/cxf/RestServiceExceptionMapper.java#L102-L110

>>>>

-- 
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/


Mime
View raw message