syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Managing WebApplicationException
Date Thu, 22 Sep 2016 12:48:46 GMT
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.

Thanks, Sergey

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


-- 
Sergey Beryozkin

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

Mime
View raw message