[
https://issues.apache.org/jira/browse/CXF-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971708#action_12971708
]
Fred Dushin commented on CXF-3191:
----------------------------------
I've done a little bit of analysis on this defect, and have found the
following. If anyone has a better understanding of SOAP exception processing
on the outbound interceptor channel, or of the expected definition of generated
exception types, please let me know!
1. As shown in the submitted test case, a declared exception is getting thrown
from the server.
2. This exception gets caught in the AbstractInvoker, and an
org.apache.cxf.interceptor.Fault seems to be properly created (wrapping the
declared exception), and is thrown from the Invoker
3. This exception ultimately gets caught in the
PhaseInterceptorChain.doIntercept method, and which point the previously
invoked interceptors are all unwound (all the interceptor handlers here seem to
be no-ops, when it comes to exception handling), and a new Message is created
and passed off to the faultObserver, which is an OutFaultChainInitiatorObserver.
4. This initiator will set up the message and exchange objects properly, and
create a new phase interceptor chain, for writing the fault back to the client.
This chain includes the Stax handlers, SOAP interceptors, and message senders.
Curious behaviors:
5. One of the out interceptors is a WebFaultOutInterceptor. One of the things
this interceptor does is to identify the exception that caused the error
(ThrowMe, in this case), and to use reflection to call the getFaultInfo method
on the exception (if it exists). In our case, this method is defined as:
public org.apache.cxf.test.ThrowMeType getFaultInfo() {
return this.throwMe;
}
were this.throwMe is declared as:
private org.apache.cxf.test.ThrowMeType throwMe;
i.e., its value is null.
This faultInfo object, whose value is null, is then passed off to a
DataWriter<Node> write operation, which in this case appears to do nothing
(because the faultInfo is null, and apparently the ThrowMe type is not nillible
-- DataWriteImpl.needToRender).
6. The Soap11FaultOutInterceptor is eventually called, and gets the Fault off
the message. A SoapFault object is created, which contains the cause
(ThrowMe), but fails to write the cause to the XMLStreamWriter.
> SOAP binding is not propagating checked exceptions through interfaces
> generated from IDL
> ----------------------------------------------------------------------------------------
>
> Key: CXF-3191
> URL: https://issues.apache.org/jira/browse/CXF-3191
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
> Affects Versions: 2.2.12
> Reporter: Fred Dushin
> Attachments: CXF-3191.tar.gz
>
>
> I have generated WSDL and Java sources from IDL.
> The IDL contains the definition of an interface with an operation that
> contains a checked exception (which is also defined in IDL).
> The servant throws this exception in its implementation.
> However, the exception is not getting propagated back to the client; instead,
> the client is receiving a javax.xml.ws.soap.SOAPFaultException.
> I have confirmed separately that the causing exception is not getting
> marshaled back to the client.
> Stand-alone test case (maven) to be submitted shortly.
> I will add any subsequent analysis to this ticket.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
