We did as suggested, but the error remains the same.
Upon closer inspection, we are confused by the way wsdl2java has
interpreted the WSDL to generate the Java code.
Looking at the WSDL, we expect the operation's response to contain the
elements "submitRawBidSetResponse/outputDataType", shown below with full
namespace for clarity:
<{http://www.caiso.com/soa/2007-08-16/submitRawBidSet.wsdl}submitRawBidS
etResponse>
<{http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd}outputDat
aType>
</>
</>
Or maybe only the inner element "outputDataType":
<{http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd}outputDat
aType>
</>
However, the generated Java code has this signature,
which uses the namespace from one of the above elements and the local
part of the other:
@WebResult(name = "outputDataType"
, targetNamespace =
"http://www.caiso.com/soa/2007-08-16/submitRawBidSet.wsdl";
, partName = "outputDataType")
As a result of this mismatch, the response from the service cannot be
parsed.
Is the signature of the generated Java code correct?
How can we get around this?
(All comments below are ours.)
<wsdl:definitions
targetNamespace =
"http://www.caiso.com/soa/2007-08-16/submitRawBidSet.wsdl";
xmlns:tns1 = "http://www.caiso.com/soa/2007-08-16/submitRawBidSet";
xmlns:tns =
"http://www.caiso.com/soa/2007-08-16/submitRawBidSet.wsdl";
xmlns:typeFault =
"http://www.caiso.com/soa/2006-06-13/StandardOutput.xsd";
xmlns:typeIn =
"http://www.caiso.com/soa/2006-06-13/StandardAttachmentInfor.xsd";
xmlns:typeOut =
"http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd";
">
<wsdl:operation name="submitRawBidSet">
<wsdl:input message="tns:submitRawBidSetRequest"/>
<wsdl:output message="tns:submitRawBidSetResponse"/>
<!--
{http://www.caiso.com/soa/2007-08-16/submitRawBidSet.wsdl}submitRawBidSe
tResponse -->
<wsdl:fault name="faultReturn" message="tns:faultReturnType"/>
</wsdl:operation>
<!-- Definition of the expected response message -->
<wsdl:message name="submitRawBidSetResponse">
<wsdl:part name="outputDataType" type="typeOut:outputDataType"/>
<!--
{http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd}outputData
Type -->
</wsdl:message>
<!-- Definition of the "outputDataType" type -->
<xs:schema
xmlns:m="http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd";
targetNamespace="http://www.caiso.com/soa/2006-06-13/SubmitStandardOutpu
t.xsd"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
>
<xs:element name="outputDataType" type="m:outputDataType"/>
<!--
{http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd}outputData
Type -->
<xs:complexType name="outputDataType">
// CXF-generated code
SubmitRawBidSet.java
@WebResult(name = "outputDataType"
, targetNamespace =
"http://www.caiso.com/soa/2007-08-16/submitRawBidSet.wsdl";
, partName = "outputDataType")
@WebMethod(action =
"http://www.caiso.com/soa/2007-08-16/submitRawBidSet";)
public com.caiso.soa._2006_06_13.submitstandardoutput.OutputDataType
submitRawBidSet(
@WebParam(partName = "rawBidSet_attachment", name =
"rawBidSet_attachment")
byte[] rawBidSetAttachment
) throws FaultReturnType;
<!-- Response from operation "submitRawBidSet" -->
<soapenv:Envelope><soapenv:Body>
<ns1:submitRawBidSetResponse
xmlns="http://www.caiso.com/soa/2007-08-16/submitRawBidSet";
xmlns:ns1="http://www.caiso.com/soa/2007-08-16/submitRawBidSet";>
<ns2:outputDataType
xmlns="http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd";
xmlns:ns2="http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd";
>
// RPCInInterceptor throws exception when parsing above message
Caused by: org.apache.cxf.interceptor.Fault:
Found element
{http://www.caiso.com/soa/2006-06-13/SubmitStandardOutput.xsd}outputData
Type
but could not find matching RPC/Literal part
at
org.apache.cxf.binding.soap.interceptor.RPCInInterceptor.handleMessage(R
PCInInterceptor.java:128)
Thanks,
Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY 10577
[EMAIL PROTECTED]
-----Original Message-----
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2008 2:13 PM
To: [email protected]
Cc: cxf-ea; Saveliff, James (IT)
Subject: Re: CXF Error | Found element ... but could not find matching
RPC/Literal part
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
--------------------------------------------------------
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.
