DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14844>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14844 SOAP Array deserialization bug [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | Version|1.0-rc2 |1.1beta ------- Additional Comments From [EMAIL PROTECTED] 2002-12-16 15:24 ------- Hi, I'm sorry to reopen this bug that I created one month ago and participate to close later, but the problem is still there and was hidden by a modification of my code until this week when I remove it. You will find here after the stack trace I obtain with the 1.1 beta, by using the : - http://live.capescience.com/wsdl/GlobalWeather.wsdl WSDL, - searchByCountry operation with "macau" as country parameter, - the DDI API to invoke the previous operation. I would like to point out that I don't generate Java code from the WSDL with WSDLToJava nor have I several java classes to represent the complex types of the WSDL. So the xml type information (known from the WSDL or the xsi:type attribute) is very important for us to determine dynamically which serializer/desrializer to activate for an XML element. Note that if the standard axis framework is used with this example, in particular the generated datas classes and serializer/deserializer, nothing may be noticed during the deserialization because in that case the Java class is sufficient to determine which deserializer to activate. - Exception: org.xml.sax.SAXException: Bad types (class [Ljava.lang.Object; -> class ilog.rules.factory.IlrDynamicArray) at org.apache.axis.message.RPCHandler.onStartChild(RPCHandler.java:302) at org.apache.axis.encoding.DeserializationContextImpl.startElement (DeserializationContextImpl.java:912) at org.apache.axis.message.SAX2EventRecorder.replay (SAX2EventRecorder.java:200) at org.apache.axis.message.MessageElement.publishToHandler (MessageElement.java:693) at org.apache.axis.message.RPCElement.deserialize(RPCElement.java:221) at org.apache.axis.message.RPCElement.getParams(RPCElement.java:323) at org.apache.axis.client.Call.invoke(Call.java:2082) at org.apache.axis.client.Call.invoke(Call.java:1986) at org.apache.axis.client.Call.invoke(Call.java:1509) at ilog.rules.webservices.client.runtime.IlrWSClassDriver$WSReflectServiceInvoker.i nvokeRequestResponseMode(IlrWSClassDriver.java:288) So the received XML message body just before the crash is : <SOAP-ENV:Body SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";> <cc2:searchByCountryResponse xmlns:cc2="capeconnect:GlobalWeather:StationInfo" SOAP-ENC:root="1"> <return xsi:type="cc1:ArrayOfStation" SOAP-ENC:arrayType="cc1:Station [1]"><item xsi:type="cc1:Station"> <icao xsi:type="xsd:string">VMMC</icao><wmo xsi:type="xsd:string">45011</wmo><iata xsi:type="xsd:string">MFM</iata><elevation xsi:type="xsd:double">114.0</elevation><latitude xsi:type="xsd:double">22.167</latitude><longitude xsi:type="xsd:double">113.567</longitude><name xsi:type="xsd:string">Taipa</name><region xsi:nil="true"/><country xsi:type="xsd:string">Macau</country><string xsi:type="xsd:string">VMMC (MFM) - Taipa, Macau @ 22.167'N 113.567'E 114m</string></item></return></cc2:searchByCountryResponse></SOAP-ENV:Body> In details, the problem is coming when the <result> structure is deserialized. This structure has been typed by the server with the xsi:type="cc1:ArrayOfStation" attribute. The deserialization processing begins in the org.apache.axis.message.RPCHandler.onStartChild method. Between line 192 and line 197, the type is determined using the XML attributes. The "typeFromAttr00" trace at line 200 indicates that this types is set to {http://schemas.xmlsoap.org/soap/encoding/}Array and not {http://www.capeclear.com/GlobalWeather.xsd}ArrayOfStation as it should be for the "return" element. Then, between line 276 and 286, an incorrect deserializer is determined from the previous XML type, that is, the default one instead of my specialized deserializer. Hence, the Java type checking line 301 between the XSI mapped type and expected Java type is not validated and raises the "Bad type exception". So, the problem comes from the result of the DeserializationContext.getTypeFromAttributes method thar returns an incorrect value for the XML type of the "return" structure. I hope my explaination be clear enough to help in reproducing this problem of bad XML typing. To conclude, we are developping a sample around the GLobalWeather WSDL, and it is critical for us to fix or find quickly a workaround to continue and deliver our current work. I thank for your help. Best regards. Philippe Bonnard.
