cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bin Zhu <>
Subject Re: no WebServiceException caught when invoking a method which returns null using the rpc/literal style
Date Fri, 18 Jan 2013 10:22:50 GMT
Hi Freeman,
Thanks very much for your quick response.
I compared my cases and yours today and refined my service
implementation as yours, but the problem still exists in my test.
Finally, I tried to migrate your cases to my CXF env(2.6.2), and the
problem still exist:
Client will not catch the WebServiceException while the server will
throw the Fault as following: Interceptor for
has thrown exception, unwinding now
Cannot write part out. RPC/Literal parts cannot be null. (WS-I BP R2211).
I'm wondering is it possible that this is an issue specific to
CXF2.6.2? As now I don't has other CXF version env, I didn't test it
on other CXF version yet. Will try to set up new env with higher CXF
version and verify it in future.
One thing I want to mention is this issue only exists when invoking
the return null method but not the null parameter method. If client
call a method with a null parameter, then there will be the
WebServiceException caught in the client side.
As the invoking and implementation of return null method and null
parameter method is similar in my case, so it seems that there should
be no problem with my usage in the return null method scenario.

2013/1/17, Freeman Fang <>:
> Hi,
> I just added a test[1] which demonstrate how cxf follow this spec. Please
> take a look.
> [1]
> -------------
> Freeman(Yue) Fang
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Web: |
> Twitter: freemanfang
> Blog:
> weibo: @Freeman小屋
> On 2013-1-17, at 下午1:27, Bin Zhu wrote:
>> Hi all,
>> Accdoring to jsr224, due to the limitations described in
>> section 5.3.1 of theWS-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.
>> (Null Values in rpc/literal): If a null value is passed as an
>> argument to amethod, or returned
>> from amethod, that uses the rpc/literal style, then an implementation
>> MUST throw a WebServiceException.
>> However, in my test application using CXF 2.6.2, when when invoking a
>> method which returns null using the rpc/literal style, their will be
>> no  WebServiceException caught. Is this possible an issue in CXF?
>> Here is the test code:
>>            try{
>>                System.out.flush(); System.err.flush();
>>                System.out.println("invoking method that returns null,
>> expecting exception");
>>                System.out.println("s.returnNull="+s.returnNull("hello
>> there null"));
>>            } catch (WebServiceException e){
>>                System.out.println("caught expected WebserviceException");
>>                e.printStackTrace();
>>                System.out.flush(); System.err.flush();
>>                ok = true;
>>            }
>>             Assert.assertTrue("Wrong/No exception received for null
>> return", ok);
>> I looked into the SOAP message/CXF code, there is Fault thrown in CXF,
>> however, the test code can't get the WebServiceException as requested
>> in the spec.
>> SOAP message:
>> <soap:Envelope
>> xmlns:soap=""><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>"
>> Related code in
>> /cxf-rt-bindings-soap/src/main/java/org/apache/cxf/binding/soap/interceptor/
>>                if (objs.hasValue(part)) {
>>                    Object o = objs.get(part);
>>                    if (o == null) {
>>                        //WSI-BP R2211 - RPC/Lit parts are not allowed
>> to be xsi:nil
>>                        throw new Fault(
>>                            new
>> org.apache.cxf.common.i18n.Message("BP_2211_RPCLIT_CANNOT_BE_NULL",
>> LOG, part.getConcreteName()));
>>                    }

View raw message