cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kyle Lape (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-6127) Check entire cause chain for SOAPFaultException
Date Thu, 11 Dec 2014 19:52:13 GMT

    [ https://issues.apache.org/jira/browse/CXF-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14243033#comment-14243033
] 

Kyle Lape commented on CXF-6127:
--------------------------------

Sorry for bouncing between jira and github.

>From your github comment:

bq. Furthermore, when the soap-fault is extracted from one-depth below, the code that follows
the try-catch block also needs to be adjusted to use that fault (in contrast to the first-level
fault as it is now) to be consistent in picking the right fault information.

Let's say I want to provide all of these in my soap fault:

- A SOAP 1.2 subcode
- A {{getFaultInfo}} method to provide a "serialized service specific exception" in the fault
detail.
- Something to populate the {{faultstring}}

My first thought was to try and have my checked exception extend {{SOAPFaultException}} and
implement {{getFaultInfo}}.  This would work according to spec if I supplied a {{faultstring}}
via {{SOAPFaultException.getFault().getFaultString()}}, but that's not implemented in CXF.
 I also can't provide one via {{Exception.getMessage()}} since I can't pass that into the
constructor for {{SOAPFaultException}}.

So I decided to set {{SOAPFaultException}} as the cause so that my checked {{@WebFault Exception}}
could provide the fault detail and fault string, while the {{SOAPFaultException}} could provide
the subcodes.  This requires the change in this jira (the recursive {{getCause()}} loop is
not necessary), and it also requires CXF to check the top-level exception for some things,
and the {{SOAPFaultException}} for others.

Looking back on section 10.2.2.3 of the jaxws spec, there seem to be more issues than I first
noticed:

- I don't see where CXF checks {{SOAPFaultException.getFault().getFaultString()}} for the
{{faultstring}}
- Neither do I see it try {{Exception.toString()}} for {{faultstring}} if option 1 and 2 fail
- I don't see CXF check for {{SOAPFaultException.getFault().getFaultActor()}} to get {{faultactor}},
though I've never tested this
- {{SOAPFaultException.getFault().getDetail()}} is not checked when creating a fault info
bean fails for whatever reason

Obviously these things aren't dealbreakers since no one's cared enough to fix them yet (i.e.
I'm not saying the should be fixed as part of this jira), but I think my point is that consistency
in the source of fault information is irrelevant -- it's the order defined in the spec that
matters.  If CXF was implemented precisely to spec, I would have several options available
to get all my soap fault fields populated as I'd like.


> Check entire cause chain for SOAPFaultException
> -----------------------------------------------
>
>                 Key: CXF-6127
>                 URL: https://issues.apache.org/jira/browse/CXF-6127
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-WS Runtime
>            Reporter: Kyle Lape
>            Assignee: Akitoshi Yoshida
>
> Section 10.2.2.3 of JAX-WS 2.2 spec has a footnote that says:
> bq. If the exception is a SOAPFaultException or has a cause that is a SOAPFaultException.
> Currently CXF only checks if the thrown exception is of the exact type (i.e. not a subtype
of) {{SOAPFaultException}}.  We need to check all causes and may as well use {{instanceof}}
rather than {{ex.getClass().equals(SOAPFaultException.class)}} in {{WebFaultOutInterceptor}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message