You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Manolescu, Radu (IT)" <Ra...@MorganStanley.com> on 2008/08/01 00:02:43 UTC
RE: CXF Error | Found element ... but could not find matching RPC/Literal part
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
Radu.Manolescu@MorganStanley.com
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: Friday, July 18, 2008 2:13 PM
To: users@cxf.apache.org
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:
> [org.apache.cxf.interceptor.StaxInInterceptor@1df503b,
> org.apache.cxf.binding.soap.interceptor.SoapActionInInterceptor@c5dbb,
> org.apache.cxf.binding.soap.interceptor.RPCInInterceptor@1ddc3ea, ...
>
> 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
> Radu.Manolescu@MorganStanley.com
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Thursday, July 17, 2008 2:25 PM
> To: users@cxf.apache.org
> 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
>> Radu.Manolescu@MorganStanley.com
>> --------------------------------------------------------
>>
>> 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
> dkulp@apache.org
> 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
dkulp@apache.org
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.
RE: CXF Error | Found element ... but could not find matching
RPC/Literal part
Posted by Glen Mazza <gl...@gmail.com>.
Manolescu, Radu (IT) wrote:
>
> This worked, thank you!
>
> Radu Manolescu
> Morgan Stanley | Technology
> 2000 Westchester Ave, 1st Floor | Purchase, NY 10577
>
OK, Dan Kulp gets a free Pepsi, I guess... ;-)
--
View this message in context: http://www.nabble.com/CXF-Error-%7C-Found-element-...-but-could-not-find-matching-RPC-Literal-part-tp18514689p18882275.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: CXF Error | Found element ... but could not find matching RPC/Literal part
Posted by "Manolescu, Radu (IT)" <Ra...@MorganStanley.com>.
This worked, thank you!
We have extended DepthXMLStreamReader and in an interceptor in the
RECEIVE phase we have replaced the XMLStreamReader with an instance of
our DepthXMLStreamReader subclass.
Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY 10577
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: Monday, August 04, 2008 4:29 PM
To: users@cxf.apache.org
Cc: Manolescu, Radu (IT); cxf-ea; Saveliff, James (IT)
Subject: Re: CXF Error | Found element ... but could not find matching
RPC/Literal part
On Monday 04 August 2008 4:15:39 pm Manolescu, Radu (IT) wrote:
> We must accept the messages sent by the service as they are, since we
> cannot request it to be modified.
> We are thinking of writing an interceptor that would use XSL to modify
> the incoming message to make it WS-I BP compliant.
> Does this approach make sense? Is there a standard interceptor for
> this, where we can configure the stylesheet to be used?
> We are looking at StaxInInterceptor as a model for our new
interceptor.
> Is there another more appropriate interceptor?
>
> We have developed an XSL stylesheet that removes all namespaces from
> the incoming message.
> Would this be sufficient to make the incoming messages WS-I BP
> compliant?
Probably not. If the schemas have a elementFormDefault="qualified",
then the
child elements should be qualified. That, and the direct child of
soap:body
needs to be qualified as well. Using an XSLT would also be slower than
need
be. Use of the XSLT would require loading the whole message in (most
likely
into a dom) where it's transformed.
However, I think you're on the right track. I would SUGGEST creating a
subclass of our DepthXMLStreamReader that overrides the public QName
getName() public String getNamespaceURI()
To do something like:
public QName getName() {
QName qn = super.getName();
if (getDepth() == 4) {
// need to double check the depth. 4 is
// env/body/wrapper/part so should be OK
qn = new QName("", qn.getLocalPart());
}
return qn;
}
(and likewise for getNamespaceURI())
In an interceptor immediately AFTER the StaxInInterceptor, grab the
reader and wrapper it with your implementation.
Dan
>
> Thanks,
>
>
> Radu Manolescu
> Morgan Stanley | Technology
> 2000 Westchester Ave, 1st Floor | Purchase, NY 10577
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Friday, August 01, 2008 12:12 PM
> To: users@cxf.apache.org
> Cc: cxf-ea; Saveliff, James (IT)
> Subject: Re: CXF Error | Found element ... but could not find matching
> RPC/Literal part
>
>
> Well, that SOAP response is NOT valid according to WSI Basic Profile
> rules for RPC/Lit.
>
> The part accessors for RPC message should NOT be namespace qualified.
> Thus, the response message is invalid.
>
> Also, the message part:
> <wsdl:part name="outputDataType" type="typeOut:outputDataType"/> is a
> type (not element, which is correct for rpc/lit)
>
> Thus, the element would take on the target namespace of the wsdl where
> it's defined. It wouldn't take on the namespace of the type.
>
> In anycase, this is a bug in the other service that is producing that
> message. It is not producing a correct message.
>
> Dan
>
> On Jul 31, 2008, at 6:02 PM, Manolescu, Radu (IT) wrote:
> > 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/SubmitStandardOut
> pu
>
> > 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.xs
> d
>
> > "
> >
> >
> > // 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
> > Radu.Manolescu@MorganStanley.com
> >
> > -----Original Message-----
> > From: Daniel Kulp [mailto:dkulp@apache.org]
> > Sent: Friday, July 18, 2008 2:13 PM
> > To: users@cxf.apache.org
> > 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:
> >> [org.apache.cxf.interceptor.StaxInInterceptor@1df503b,
> >> org
> >> .apache.cxf.binding.soap.interceptor.SoapActionInInterceptor@c5dbb,
> >> org.apache.cxf.binding.soap.interceptor.RPCInInterceptor@1ddc3ea,
...
> >>
> >> 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
> >> Radu.Manolescu@MorganStanley.com
> >>
> >> -----Original Message-----
> >> From: Daniel Kulp [mailto:dkulp@apache.org]
> >> Sent: Thursday, July 17, 2008 2:25 PM
> >> To: users@cxf.apache.org
> >> 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}outputDataTyp
> >>> e
> >>> 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
> >>> Radu.Manolescu@MorganStanley.com
> >>> --------------------------------------------------------
> >>>
> >>> 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
> >> dkulp@apache.org
> >> 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
> > dkulp@apache.org
> > 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
> dkulp@apache.org
> 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
dkulp@apache.org
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.
Re: CXF Error | Found element ... but could not find matching RPC/Literal part
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 04 August 2008 4:15:39 pm Manolescu, Radu (IT) wrote:
> We must accept the messages sent by the service as they are, since we
> cannot request it to be modified.
> We are thinking of writing an interceptor that would use XSL to modify
> the incoming message to make it WS-I BP compliant.
> Does this approach make sense? Is there a standard interceptor for this,
> where we can configure the stylesheet to be used?
> We are looking at StaxInInterceptor as a model for our new interceptor.
> Is there another more appropriate interceptor?
>
> We have developed an XSL stylesheet that removes all namespaces from the
> incoming message.
> Would this be sufficient to make the incoming messages WS-I BP
> compliant?
Probably not. If the schemas have a elementFormDefault="qualified", then the
child elements should be qualified. That, and the direct child of soap:body
needs to be qualified as well. Using an XSLT would also be slower than need
be. Use of the XSLT would require loading the whole message in (most likely
into a dom) where it's transformed.
However, I think you're on the right track. I would SUGGEST creating a
subclass of our DepthXMLStreamReader that overrides the
public QName getName()
public String getNamespaceURI()
To do something like:
public QName getName() {
QName qn = super.getName();
if (getDepth() == 4) {
// need to double check the depth. 4 is
// env/body/wrapper/part so should be OK
qn = new QName("", qn.getLocalPart());
}
return qn;
}
(and likewise for getNamespaceURI())
In an interceptor immediately AFTER the StaxInInterceptor, grab the reader and
wrapper it with your implementation.
Dan
>
> Thanks,
>
>
> Radu Manolescu
> Morgan Stanley | Technology
> 2000 Westchester Ave, 1st Floor | Purchase, NY 10577
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Friday, August 01, 2008 12:12 PM
> To: users@cxf.apache.org
> Cc: cxf-ea; Saveliff, James (IT)
> Subject: Re: CXF Error | Found element ... but could not find matching
> RPC/Literal part
>
>
> Well, that SOAP response is NOT valid according to WSI Basic Profile
> rules for RPC/Lit.
>
> The part accessors for RPC message should NOT be namespace qualified.
> Thus, the response message is invalid.
>
> Also, the message part:
> <wsdl:part name="outputDataType" type="typeOut:outputDataType"/>
> is a type (not element, which is correct for rpc/lit)
>
> Thus, the element would take on the target namespace of the wsdl where
> it's defined. It wouldn't take on the namespace of the type.
>
> In anycase, this is a bug in the other service that is producing that
> message. It is not producing a correct message.
>
> Dan
>
> On Jul 31, 2008, at 6:02 PM, Manolescu, Radu (IT) wrote:
> > 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
> > Radu.Manolescu@MorganStanley.com
> >
> > -----Original Message-----
> > From: Daniel Kulp [mailto:dkulp@apache.org]
> > Sent: Friday, July 18, 2008 2:13 PM
> > To: users@cxf.apache.org
> > 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:
> >> [org.apache.cxf.interceptor.StaxInInterceptor@1df503b,
> >> org
> >> .apache.cxf.binding.soap.interceptor.SoapActionInInterceptor@c5dbb,
> >> org.apache.cxf.binding.soap.interceptor.RPCInInterceptor@1ddc3ea, ...
> >>
> >> 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
> >> Radu.Manolescu@MorganStanley.com
> >>
> >> -----Original Message-----
> >> From: Daniel Kulp [mailto:dkulp@apache.org]
> >> Sent: Thursday, July 17, 2008 2:25 PM
> >> To: users@cxf.apache.org
> >> 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
> >>> Radu.Manolescu@MorganStanley.com
> >>> --------------------------------------------------------
> >>>
> >>> 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
> >> dkulp@apache.org
> >> 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
> > dkulp@apache.org
> > 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
> dkulp@apache.org
> 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
dkulp@apache.org
http://www.dankulp.com/blog
RE: CXF Error | Found element ... but could not find matching RPC/Literal part
Posted by "Manolescu, Radu (IT)" <Ra...@MorganStanley.com>.
We must accept the messages sent by the service as they are, since we
cannot request it to be modified.
We are thinking of writing an interceptor that would use XSL to modify
the incoming message to make it WS-I BP compliant.
Does this approach make sense? Is there a standard interceptor for this,
where we can configure the stylesheet to be used?
We are looking at StaxInInterceptor as a model for our new interceptor.
Is there another more appropriate interceptor?
We have developed an XSL stylesheet that removes all namespaces from the
incoming message.
Would this be sufficient to make the incoming messages WS-I BP
compliant?
Thanks,
Radu Manolescu
Morgan Stanley | Technology
2000 Westchester Ave, 1st Floor | Purchase, NY 10577
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: Friday, August 01, 2008 12:12 PM
To: users@cxf.apache.org
Cc: cxf-ea; Saveliff, James (IT)
Subject: Re: CXF Error | Found element ... but could not find matching
RPC/Literal part
Well, that SOAP response is NOT valid according to WSI Basic Profile
rules for RPC/Lit.
The part accessors for RPC message should NOT be namespace qualified.
Thus, the response message is invalid.
Also, the message part:
<wsdl:part name="outputDataType" type="typeOut:outputDataType"/>
is a type (not element, which is correct for rpc/lit)
Thus, the element would take on the target namespace of the wsdl where
it's defined. It wouldn't take on the namespace of the type.
In anycase, this is a bug in the other service that is producing that
message. It is not producing a correct message.
Dan
On Jul 31, 2008, at 6:02 PM, Manolescu, Radu (IT) wrote:
> 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
> Radu.Manolescu@MorganStanley.com
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Friday, July 18, 2008 2:13 PM
> To: users@cxf.apache.org
> 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:
>> [org.apache.cxf.interceptor.StaxInInterceptor@1df503b,
>> org
>> .apache.cxf.binding.soap.interceptor.SoapActionInInterceptor@c5dbb,
>> org.apache.cxf.binding.soap.interceptor.RPCInInterceptor@1ddc3ea, ...
>>
>> 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
>> Radu.Manolescu@MorganStanley.com
>>
>> -----Original Message-----
>> From: Daniel Kulp [mailto:dkulp@apache.org]
>> Sent: Thursday, July 17, 2008 2:25 PM
>> To: users@cxf.apache.org
>> 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
>>> Radu.Manolescu@MorganStanley.com
>>> --------------------------------------------------------
>>>
>>> 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
>> dkulp@apache.org
>> 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
> dkulp@apache.org
> 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
dkulp@apache.org
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.
Re: CXF Error | Found element ... but could not find matching RPC/Literal part
Posted by Daniel Kulp <dk...@apache.org>.
Well, that SOAP response is NOT valid according to WSI Basic Profile
rules for RPC/Lit.
The part accessors for RPC message should NOT be namespace qualified.
Thus, the response message is invalid.
Also, the message part:
<wsdl:part name="outputDataType" type="typeOut:outputDataType"/>
is a type (not element, which is correct for rpc/lit)
Thus, the element would take on the target namespace of the wsdl where
it's defined. It wouldn't take on the namespace of the type.
In anycase, this is a bug in the other service that is producing that
message. It is not producing a correct message.
Dan
On Jul 31, 2008, at 6:02 PM, Manolescu, Radu (IT) wrote:
> 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
> Radu.Manolescu@MorganStanley.com
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Friday, July 18, 2008 2:13 PM
> To: users@cxf.apache.org
> 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:
>> [org.apache.cxf.interceptor.StaxInInterceptor@1df503b,
>> org
>> .apache.cxf.binding.soap.interceptor.SoapActionInInterceptor@c5dbb,
>> org.apache.cxf.binding.soap.interceptor.RPCInInterceptor@1ddc3ea, ...
>>
>> 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
>> Radu.Manolescu@MorganStanley.com
>>
>> -----Original Message-----
>> From: Daniel Kulp [mailto:dkulp@apache.org]
>> Sent: Thursday, July 17, 2008 2:25 PM
>> To: users@cxf.apache.org
>> 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
>>> Radu.Manolescu@MorganStanley.com
>>> --------------------------------------------------------
>>>
>>> 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
>> dkulp@apache.org
>> 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
> dkulp@apache.org
> 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
dkulp@apache.org
http://www.dankulp.com/blog