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.
