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