cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Wellington (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CXF-1848) Can't specify SOAP faultcode for Exceptions that use @WebFault
Date Tue, 07 Oct 2008 22:48:44 GMT

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

Sean Wellington updated CXF-1848:
---------------------------------

    Description: 
All exceptions with @WebFault annotation are forced to carry a SOAP faultcode of "Server".
There is no way to change this.

I traced through the code and the logic in AbstractInvoker seems to be:

1. If the exception is a subclass of Fault, throw it as-is;
2. Otherwise wrap it in a new instance of Fault, and use the faultcode of "Server" as a default.

This is fine until the exception bubbles up to WebFaultOutInterceptor, around line 94, where
it filters out anything that isn't a subclass of exception (Fault is a RuntimeException).
So the net effect is that the getFaultInfo() specified by @WebFault method is ignored.

The only workaround is to totally roll your own exception responses using the DOM APIs via
Fault.getDetails(). This is undesirable.


  was:
All exceptions with @WebFault annotation are forced to carry a SOAP faultcode of "Server".
There is no way to change this.

I traced through the code and the logic in AbstractInvoker seems to be:

1. If the exception is a subclass of Fault, throw it as-is;
2. Otherwise wrap it in a new instance of Fault, and use the faultcode of "Server" as a default.

This is fine until the exception bubbles up to WebFaultOutInterceptor, around line 94, where
it filters out anything that isn't a subclass of exception (Fault is a RuntimeException).
So the net effect is that the getFaultInfo() method is ignored.

The only workaround is to totally roll your own exception responses using the DOM APIs via
Fault.getDetails(). This is undesirable.



> Can't specify SOAP faultcode for Exceptions that use @WebFault
> --------------------------------------------------------------
>
>                 Key: CXF-1848
>                 URL: https://issues.apache.org/jira/browse/CXF-1848
>             Project: CXF
>          Issue Type: Improvement
>          Components: JAX-WS Runtime, Soap Binding
>    Affects Versions: 2.1.2
>            Reporter: Sean Wellington
>
> All exceptions with @WebFault annotation are forced to carry a SOAP faultcode of "Server".
There is no way to change this.
> I traced through the code and the logic in AbstractInvoker seems to be:
> 1. If the exception is a subclass of Fault, throw it as-is;
> 2. Otherwise wrap it in a new instance of Fault, and use the faultcode of "Server" as
a default.
> This is fine until the exception bubbles up to WebFaultOutInterceptor, around line 94,
where it filters out anything that isn't a subclass of exception (Fault is a RuntimeException).
So the net effect is that the getFaultInfo() specified by @WebFault method is ignored.
> The only workaround is to totally roll your own exception responses using the DOM APIs
via Fault.getDetails(). This is undesirable.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message