axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 14844] - SOAP Array deserialization bug
Date Mon, 16 Dec 2002 15:24:56 GMT
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

pbonnard@ilog.fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |
            Version|1.0-rc2                     |1.1beta



------- Additional Comments From pbonnard@ilog.fr  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&apos;N 113.567&apos;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.

Mime
View raw message