Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 76878 invoked by uid 500); 31 Jan 2002 18:11:41 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 76867 invoked from network); 31 Jan 2002 18:11:41 -0000 Subject: Re: AXIS/SOAP Interop Test Summary To: axis-dev@xml.apache.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "R J Scheuerle Jr" Date: Thu, 31 Jan 2002 12:11:42 -0600 X-MIMETrack: Serialize by Router on D04NM202/04/M/IBM(Release 5.0.9 |November 16, 2001) at 01/31/2002 01:11:43 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Problem: -------------- The 4s4c 2.0 echoStructArray return does does not contain enough type information for Axis to understand how to deserialize the array. The returned format has xsi:type=soapenc:Array and soapenc:arrayType=xsd:anyType[3], and the elements of the array do not have xsi:type attributes. Possible Solution: --------------------------- For non-array types without xsi:type information, the expected return type is consulted to determine how to deserialize the object. (RPCHandler) In this case we, have an xsi:type=soapenc:Array, but still not enough information to deserialize the array. Should we change RPCHandler to recognize this case and consult the return type? (Which in this case will be ArrayOfSOAPStruct which maps to SOAPStruct[]) Summary of Proposed Solution: ----------------------------------------------- If the xsi:type=soapenc:Array and the soapenc:arrayType is too generic (i.e. xsd:anyType), then use the type information of the Return type. Comments? Rich Scheuerle XML & Web Services Development 512-838-5115 (IBM TL 678-5115) R J Scheuerle Jr/Austin/IBM@IBM To: axis-dev@xml.apache.org US cc: Subject: AXIS/SOAP Interop Test Summary 01/31/2002 07:53 AM Please respond to axis-dev The number of red failures in the last run: 35 The number of red failures in the jan 1 run: 41 Test Missing Service Other ----------------------------------- Float 1 (TCLSoap returned correct value, but it's a xsd:double) Struct 1 (Soapx4 doesn't support multi-ref) StructArray 6 (4s4c return provides incomplete type info, Frontier return clear has an invalid type, HP returns an exception, Soapx4 doesn't support multi-ref SQLData doesn't send back all of the elements TclSoap returns a parsing exception) Void 2 (SoapX4 and TclSoap both return elements with no values) Base64 1 2 (SoapX4 and Spheon both had type mismatches) Hex Binary 6 2 (4s4c and 4s4c2.0 both return soapenc:base64) Date 2 1 (SoapX4 expected timeInstant not dateTime) Decimal 5 2 (424c rounded the value, ZSI returned an extra significant digit..real close!) Boolean 4 ==================================== Totals 18 + 17 = 35 ------------------------------------------------------------------------------------------- Also there are more SOAP structArray problems. Without the wire dumps its hard to tell what is going on, but I suspect that SOAP is now sending the arrays across with a type=ArrayOfSOAPStruct instead of type=soapenc:Array. SOAP may need to apply the same fix that I did to the array serializer to force type=soapenc:Array. Rich Scheuerle XML & Web Services Development 512-838-5115 (IBM TL 678-5115)