OK, so we understand that the response is not WSI-BP compatible. (Our
counterparty is using Axis.)
(Grumbling: "great, so now we have two Apache products that don't talk
to each other")
We set out to replace the standard RPCInInterceptor by our own modified
copy, which would accept the Axis messages.
We have used the code pattern below, which has proved effective in
replacing other interceptors:
// Replace RPCInInterceptor to ensure compatibility with Axis
i = 0;
for (Interceptor interceptor: binding.getInInterceptors())
{
if (interceptor instanceof RPCInInterceptor)
{
binding.getInInterceptors().remove(i);
System.out.println("RPCInInterceptor removed from
binding.");
}
}
binding.getInInterceptors().add(new MSRPCInInterceptor());
My log shows the following interceptor flow:
Current flow:
receive [LoggingInInterceptor, MSXMLStreamInInterceptor]
post-stream [StaxInInterceptor]
read [ReadHeadersInterceptor, SoapActionInInterceptor]
pre-protocol [MustUnderstandInterceptor, SOAPHandlerInterceptor,
LogicalHandlerInInterceptor]
post-protocol [CheckFaultInterceptor]
unmarshal [URIMappingInterceptor, RPCInInterceptor,
SoapHeaderInterceptor, MSRPCInInterceptor]
post-logical [WrapperClassInInterceptor]
pre-invoke [SwAInInterceptor, HolderInInterceptor]
Note that our interceptor (MSRPCInInterceptor) has been added, but the
original interceptor (RPCInInterceptor) is still there.
We also get this output, which indicates that RPCInInterceptor should
have been removed (why twice?):
RPCInInterceptor removed from binding.
RPCInInterceptor removed from binding.
We also find this in the log, indicating that the interceptor is
attached to and should be removed from the binding object (and not other
objects):
Interceptors contributed by binding:
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED], ...
What are we missing? Is there a built-in reason why RPCInInterceptor
cannot be removed from the chain?
Thanks,
Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY 10577
Phone: +1 914 225-5871
[EMAIL PROTECTED]
-----Original Message-----
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 17, 2008 2:25 PM
To: [email protected]
Cc: cxf-ea; Saveliff, James (IT)
Subject: Re: CXF Error | Found element ... but could not find matching
RPC/Literal part
The soap message is wrong for an rpc/lit response.
The <ns2:outputDataType> element should be:
<returnData>
Per RPC/Lit rules, the part accessors come from the part names in the
message/parts of the wsdl. They are also supposed to be unqualified
per wsi-bp rules (although some older toolkits do qualify them so our
RPCInInterceptor will allow that, but the out interceptor will not
qualify them).
Dan
On Jul 17, 2008, at 2:14 PM, Manolescu, Radu (IT) wrote:
> We have implemented a CXF client from a counterparty-supplied WSDL.
> As we call one operation, we get back a response containing valid
> business messages.
> However, the RPCInInterceptor throws an exception because it "could
> not
> find matching RPC/Literal part".
>
> We have checked the response, and it contains the element
> "outputDataType", which is mentioned in the exception.
> In the response, this element's namespace is declared as
> "http://www.company.com/soa/SubmitStandardOutput.xsd";.
> When we look in the WSDL, I can see that the element outputDataType is
> declared in the operation's return type, with the same namespace.
> We do not understand why CXF "could not find matching RPC/Literal
> part".
>
> We understand that CXF does not support RPC/Encoded.
> However, we have checked that the WSDL conforms to the RPC/Literal
> restrictions:
> * Each message contains zero or more parts.
> * Each part points to a schema type definition that describes the
> content of that part.
> * In the SOAP binding, the style is "RPC" and the use is
> "literal".
>
>
> What are we missing?
>
>
>
> ---------- EXCEPTION: ----------
> Caused by: org.apache.cxf.interceptor.Fault: Found element
> {http://www.company.com/soa/SubmitStandardOutput.xsd}outputDataType
> but
> could not find matching RPC/Literal part
> at
> org
> .apache.cxf.binding.soap.interceptor.RPCInInterceptor.handleMessage(R
> PCInInterceptor.java:128)
>
> ---------- RESPONSE: ----------
> <soapenv:Envelope
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> <soapenv:Body>
> <ns1:submitDataSetResponse
> xmlns="http://www.company.com/soa/submitDataSet";
>
> xmlns:ns1="http://www.company.com/soa/submitDataSet";>
> <ns2:outputDataType
>
> xmlns="http://www.company.com/soa/SubmitStandardOutput.xsd";
>
> xmlns:ns2="http://www.company.com/soa/SubmitStandardOutput.xsd";>
> <!-- Valid business content, removed
> from here for simplicity -->
> </ns2:outputDataType>
> </ns1:submitDataSetResponse>
> </soapenv:Body>
> </soapenv:Envelope>
>
> ---------- WSDL: ----------
> <?xml version="1.0" encoding="UTF-8"?>
> <wsdl:definitions targetNamespace="some namespaces omitted"
> xmlns:typeOut="http://www.company.com/soa/SubmitStandardOutput.xsd";>
> <wsdl:message name="someOpResponse">
> <wsdl:part name="returnData"
> type="typeOut:outputDataType">
> <wsdl:documentation
>
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";>
> acknowledge data set submitted
> </wsdl:documentation>
> </wsdl:part>
> </wsdl:message>
> <wsdl:portType name="SomeOp">
> <wsdl:operation name="someOp">
> <wsdl:documentation
>
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";>
> submit data set
> </wsdl:documentation>
> <wsdl:input message="tns:someOpRequest" />
> <wsdl:output message="tns:someOpResponse" />
> <wsdl:fault name="faultReturn"
> message="tns:faultReturnType" />
> </wsdl:operation>
> </wsdl:portType>
> <wsdl:binding name="SomeOp_Binding"
> type="tns:SomeOp">
> <soap:binding style="rpc"
> transport="http://schemas.xmlsoap.org/soap/http";
> />
> <wsdl:operation name="someOp">
> <soap:operation
>
> soapAction="http://www.company.com/soa/2007-08-16/someOp";
> style="rpc" />
> <wsdl:input>
> <mime:multipartRelated>
> <mime:part>
> <soap:body use="literal"
>
> namespace="http://www.company.com/soa/2007-08-16/someOp"; />
> </mime:part>
> <mime:part>
> <mime:content
> part="dataSet_attachment"
>
> type="application/octetstream" />
> </mime:part>
> </mime:multipartRelated>
> <soap:header message="tns:someOpHeader"
> part="standardAttachmentInfor"
> use="literal"
> wsdl:required="true">
> </soap:header>
> <wsp:Policy
>
> xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy";>
> <wsp:PolicyReference
> URI="#SecurityTokens" />
> <wsp:Policy wsu:Id="SignedPart1"
>
> xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility";>
> <wsp:Policy>
> <wssp:Integrity
> wsp:Usage="wsp:Required"
>
> xmlns:wssp="http://schemas.xmlsoap.org/ws/2002/12/secext";>
>
> <wssp:TokenInfo>
>
> <wssp:SecurityToken
>
> wsp:Preference="10" wsp:Usage="wsp:Required">
>
> <wssp:TokenType>
>
> wssp:X509v3
>
> </wssp:TokenType>
>
> </wssp:SecurityToken>
>
> </wssp:TokenInfo>
>
> <wssp:MessageParts
>
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
>
> xmlns:ns2="http://www.company.com/soa/StandardAttachmentInfor.xsd";>
>
> /SOAP-ENV:Envelope/SOAP-ENV:Header/ns2:standardAttachmentInfor
>
> </wssp:MessageParts>
>
> </wssp:Integrity>
> </wsp:Policy>
> <wsp:Policy>
> <wssp:Integrity
> wsp:Usage="wsp:Required"
>
> xmlns:wssp="http://schemas.xmlsoap.org/ws/2002/12/secext";>
>
> <wssp:TokenInfo>
>
> <wssp:SecurityToken
>
> wsp:Preference="10" wsp:Usage="wsp:Required">
>
> <wssp:TokenType>
>
> wssp:X509v3
>
> </wssp:TokenType>
>
> </wssp:SecurityToken>
>
> </wssp:TokenInfo>
>
> <wssp:MessageParts
>
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
>
> xmlns:ns1="http://www.company.com/soa/2006-09-30/companyWSHeader.xsd";>
>
> /SOAP-ENV:Envelope/SOAP-ENV:Header/ns1:companyWSHeader
>
> </wssp:MessageParts>
>
> </wssp:Integrity>
> </wsp:Policy>
> <wsp:Policy>
> <wssp:Integrity
> wsp:Usage="wsp:Required"
>
> xmlns:wssp="http://schemas.xmlsoap.org/ws/2002/12/secext";>
>
> <wssp:TokenInfo>
>
> <wssp:SecurityToken
>
> wsp:Preference="10" wsp:Usage="wsp:Required">
>
> <wssp:TokenType>
>
> wssp:X509v3
>
> </wssp:TokenType>
>
> </wssp:SecurityToken>
>
> </wssp:TokenInfo>
>
> <wssp:MessageParts
>
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
>
> xmlns:ns1="http://www.company.com/soa/schemas/2005/09/attachmenthash";>
>
> /SOAP-ENV:Envelope/SOAP-ENV:Header/ns1:attachmentHash
>
> </wssp:MessageParts>
>
> </wssp:Integrity>
> </wsp:Policy>
> </wsp:Policy>
> </wsp:Policy>
> </wsdl:input>
> <wsdl:output>
> <soap:body use="literal"
>
> namespace="http://www.company.com/soa/2007-08-16/someOp"; />
> </wsdl:output>
> <wsdl:fault name="faultReturn">
> <soap:fault name="faultReturn"
> use="literal" />
> </wsdl:fault>
> </wsdl:operation>
> </wsdl:binding>
> </wsdl:definitions>
>
>
>
>
> Radu Manolescu
> Morgan Stanley | Technology
> 2000 Westchester Ave, 1st Floor | Purchase, NY 10577
> Phone: +1 914 225-5871
> [EMAIL PROTECTED]
> --------------------------------------------------------
>
> NOTICE: If received in error, please destroy and notify sender.
> Sender does not intend to waive confidentiality or privilege. Use of
> this email is prohibited when received in error.
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not
intend to waive confidentiality or privilege. Use of this email is prohibited
when received in error.
