On Jul 18, 2008, at 1:33 PM, Manolescu, Radu (IT) wrote:
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")
If everyone followed the standards, their wouldn't be a
problem...... That's what standards are for. :-(
I'm really not sure why the below isn't working. That looks
completely correct. The only place we call "new RPCInInterceptor()"
in the code is:
sb.getInInterceptors().add(new RPCInInterceptor());
Thus, removing it from the binding like you are doing should work
fine. Very strange. You might need to debug into that one. :-(
Another option might be to use a locally modified WSDL. Change:
<wsdl:part name="returnData"
type="typeOut:outputDataType">
to
<wsdl:part name="outputDataType"
type="typeOut:outputDataType">
An XSLT might be able to automate that.
Dan
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.
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
