You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Freeman Fang (Jira)" <ji...@apache.org> on 2019/09/13 15:20:00 UTC

[jira] [Issue Comment Deleted] (CXF-6568) Default WebApplicationExceptionMapper should be optionally made less specific

     [ https://issues.apache.org/jira/browse/CXF-6568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Freeman Fang updated CXF-6568:
------------------------------
    Comment: was deleted

(was: Thanks for reporting this issue

Document updated, should be published in a couple of hours)

> Default WebApplicationExceptionMapper should be optionally made less specific
> -----------------------------------------------------------------------------
>
>                 Key: CXF-6568
>                 URL: https://issues.apache.org/jira/browse/CXF-6568
>             Project: CXF
>          Issue Type: Improvement
>          Components: JAX-RS
>            Reporter: Sergey Beryozkin
>            Assignee: Sergey Beryozkin
>            Priority: Minor
>             Fix For: 3.1.3, 3.0.7
>
>
> Now that the default and custom providers are kept in a single ProviderFactory with a parent-child relationship the default WebApplicationExceptionMapper will win over custom providers which are less specific (ex, RuntimeException mappers) but which expect to catch WebApplicationException.
> It is been confirmed on the spec experts list that it is expected that custom mappers can catch WAE thrown by the runtime itself therefore the fact that CXF uses WAE to enforce spec-related error conditions is sound.
> There's no clarity though how the runtime is expected to manages such runtime-originated WAEs - via its own WAE mapper or even RuntimeException mapper or somehow else.
> Therefore a property "make.default.wae.least.specific" is introduced to ensure a CXF default WAE mapper is only used if no other custom mapper can handle a given WAE to minimize any portability concerns.
> This can be further addressed once we get more clarity on the issue   



--
This message was sent by Atlassian Jira
(v8.3.2#803003)