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

Bin Zhu edited comment on CXF-4761 at 1/25/13 10:11 AM:
--------------------------------------------------------

Hi Freeman,
The Outbound SOAP message in current CXF is like below:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
   <soap:Body>
      <ns1:returnNullResponse 
xmlns:ns1="http://serverrpc.testdata.soapbinding.annotations/";>
         <soap:Fault>
            <faultcode>soap:Server</faultcode>
            <faultstring>Cannot write part return. RPC/Literal parts cannot be 
null. (WS-I BP R2211)</faultstring>
         </soap:Fault>
      </ns1:returnNullResponse>
   </soap:Body>
</soap:Envelope>
We think that the reason we can't catch the WebServiceException in Client side 
is that CXF wrapped the Fault in the common response element, which is not the 
correct behavior.
We also tested the SOAP message from Axis2 which our client can catch the 
WebServiceException as expected and found that the Fault is not wrapped in the 
response element as CXF.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
   <soapenv:Body>
      <soapenv:Fault>
         <faultcode>soapenv:Server</faultcode>
         <faultstring>Return argument(s) in operation method returnNull is 
null.  This is not allowed for rpc/lit messages.</faultstring>
         <detail/>
      </soapenv:Fault>
   </soapenv:Body>
</soapenv:Envelope>

Based on the above analysis, we made a patch for it. can you help take a look 
at it? Thanks.
                
      was (Author: zhubinbj):
    Hi Freeman,
The Outbound SOAP message in current CXF is like below:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
   <soap:Body>
      <ns1:returnNullResponse 
xmlns:ns1="http://serverrpc.testdata.soapbinding.annotations/";>
         <soap:Fault>
            <faultcode>soap:Server</faultcode>
            <faultstring>Cannot write part return. RPC/Literal parts cannot be 
null. (WS-I BP R2211)</faultstring>
         </soap:Fault>
      </ns1:returnNullResponse>
   </soap:Body>
</soap:Envelope>
We think that the reason we can't catch the WebServiceException in Client side 
is that CXF wrapped the Fault in the common response element, which is not the 
correct behavior.
We also tested the SOAP message from AIX2 which our client can catch the 
WebServiceException as expected and found that the Fault is not wrapped in the 
response element as CXF.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>
   <soapenv:Body>
      <soapenv:Fault>
         <faultcode>soapenv:Server</faultcode>
         <faultstring>Return argument(s) in operation method returnNull is 
null.  This is not allowed for rpc/lit messages.</faultstring>
         <detail/>
      </soapenv:Fault>
   </soapenv:Body>
</soapenv:Envelope>

Based on the above analysis, we made a patch for it. can you help take a look 
at it? Thanks.
                  
> ensure CXF follow jaxws spec 3.6.2.3
> ------------------------------------
>
>                 Key: CXF-4761
>                 URL: https://issues.apache.org/jira/browse/CXF-4761
>             Project: CXF
>          Issue Type: Test
>            Reporter: Freeman Fang
>            Assignee: Freeman Fang
>             Fix For: 2.5.9, 2.6.6, 2.7.3, 2.8.0
>
>         Attachments: AnnoRPCBindingTestClient.zip, 
> AnnotationsSoapBindingRpc2.ear, AnnotationsSoapBindingRpc.ear, 
> RPCOutInterceptor.java.patch
>
>
> especially 
> Due to the limitations described in section 5.3.1 of the WS-I Basic Profile 
> specification (see [8]), null values cannot be used as method arguments or as 
> the return value from a method which uses the rpc/literal binding.
> ♦Conformance(NullValuesinrpc/literal): 
> Ifanullvalueispassedasanargumenttoamethod,orreturned from a method, that uses 
> the rpc/literal style, then an implementation MUST throw a 
> WebServiceException.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to