Apache 2.2 improvements for complex/polymorphic types.

[Dmitri Lysenko <ld...@nuix.com.au>]

Hi all, 

We are using the Apache SOAP 2.2 for the project there are interoperability 
with the MS .Net and
support for the complex types are critical.

While Apache Soap 2.2 appears to handle complex types quite well(we were able 
to use the BeanSerializer to handle
invocations from the MS .Net side) there are some problems that caused me to 
do some modifications of the
server-side serialization/deserialization code.

(1) The first problem is the 2.2 version has a bug that doesn't allow to 
deserialize the arrays that  contains the
items of the different types. I consider this is the bug since this situation 
is allowed by the SOAP spec and so
should be handled properly. As a result I wasn't able to handle such arrays 
from the MS side without
org.apache.soap.encoding.soapenc.ArraySerializer source modification.

This is the diff with the original source:

Index: ArraySerializer.java
===================================================================
RCS file: 
/home/cvspublic/xml-soap/java/src/org/apache/soap/encoding/soapenc/ArraySerializer.java,v
retrieving revision 1.8
diff -u -u -r1.8 ArraySerializer.java
--- ArraySerializer.java        2001/05/19 04:37:52     1.8
+++ ArraySerializer.java        2001/10/26 00:48:35
@@ -184,6 +184,17 @@
         if (actualEl == null) {
           throw new IllegalArgumentException("No such ID '" + href + "'");
         }
+        else
+        {
+            /**
+             * The BUG was here in the original code. --lds
+             */
+            QName declType = SoapEncUtils.getTypeQName(actualEl);
+            if (declType != null)
+            {
+                actualItemType = declType;
+            }
+        }
       }
 
       Bean itemBean = xjmr.unmarshall(actualEncStyle, actualItemType,
===================================================================
 
(2) The way that the ParameterSerializer is used to locate a serializer based 
on the class type
sometimes isn't apporopriate. For instance we implement the "command pattern" 
and the soap server
exports only one method like:
Object execute(Command command). Server takes a polymorphic commands and 
returns results that depend on the
command. Obviously this method never returns the Object, it returns the 
Object's subclass, i.e.
object of any type can be returned. The behaviour of ParameterSerializer for 
this example is to look the
serializer for the Object class that is not what we need. It seems more right 
to resolve Serializer on top of the
actual type of the object. I made the patch that fixes this problem.
The diff with the ParameterSerializer is below:
 
Index: ParameterSerializer.java
===================================================================
RCS file: 
/home/cvspublic/xml-soap/java/src/org/apache/soap/encoding/soapenc/ParameterSerializer.java,v
retrieving revision 1.9
diff -u -u -r1.9 ParameterSerializer.java
--- ParameterSerializer.java    2001/05/19 04:29:02     1.9
+++ ParameterSerializer.java    2001/10/26 00:48:36
@@ -93,6 +93,11 @@
     }
     else
     {
+        // Query the actual parameter's type --lds
+        if (type == Object.class)
+        {
+            type = value.getClass();
+        }
       String declEncStyle = param.getEncodingStyleURI();
       String actualEncStyle = declEncStyle != null
                               ? declEncStyle
===================================================================
 
(3) There are a number of other simple improvements that were made to allow 
handling of complex polimorphyc
structures and to reduce the needs in the extra configuration options.

Dmitri Lyssenko,
Software programmer
Nuix Pty. Ltd.