cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dr. Dietmar Wolz (JIRA)" <>
Subject [jira] Commented: (CXF-1848) Can't specify SOAP faultcode for Exceptions that use @WebFault
Date Fri, 01 Oct 2010 12:07:35 GMT


Dr. Dietmar Wolz commented on CXF-1848:

Unfortunately I cannot reproduce the fix using CXF 2.2.10.

Tried the following:

       	        SOAPFaultException ex = null;
        	try {
				SOAPFactory factory = SOAPFactory.newInstance(SOAPConstants.SOAP_1_1_PROTOCOL);
				SOAPFault fault = factory.createFault();
	        	ex = new SOAPFaultException(fault);
			} catch (SOAPException e) {
           	  throw new ReadFaultMsg("No element with key '" 
          			+ parameters.getKey() + "'", "This is a detail!",ex);
on the wire (using a http tracer) i see the following reply

<soap:Envelope xmlns:soap=""><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>No
element with key 'Hasi'</faultstring><detail><ns2:ElementNotFoundFault xmlns:ns2="">This
is a detail!</ns2:ElementNotFoundFault></detail></soap:Fault></soap:Body></soap:Envelope>

which has "soap:Server" and not "wst:FailedAuthentication" as fault code, 
what did I wrong?

> Can't specify SOAP faultcode for Exceptions that use @WebFault
> --------------------------------------------------------------
>                 Key: CXF-1848
>                 URL:
>             Project: CXF
>          Issue Type: Improvement
>          Components: JAX-WS Runtime, Soap Binding
>    Affects Versions: 2.1.2
>            Reporter: Sean Wellington
>             Fix For: Invalid
> 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.

View raw message