axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gabor Herr (JIRA)" <>
Subject [jira] Commented: (AXIS-2267) Extended types in array incorrectly serialised as base type
Date Thu, 17 Nov 2005 16:00:42 GMT
    [ ] 

Gabor Herr commented on AXIS-2267:

This problem not only affects polymorphic array elements, but also simple polymorphic elements.
We have an xsd element that has a subelement of an abstract base type. When an element that
contains an instance of a subtype is serialized by axis, only the elements visible to the
base type are sent over the wire.

It seems that this problem is caused by a wrong if-clause in getActualJavaClass. The included
patch fixes the problem, by extending the comparison to assignment compatible classes.

Index: Axis/src/org/apache/axis/encoding/
--- Axis/src/org/apache/axis/encoding/	(revision 345250)
+++ Axis/src/org/apache/axis/encoding/	(working copy)
@@ -1533,7 +1533,7 @@
             return cls;
-        if (javaType != null && cls != javaType && !cls.isArray()) {
+        if (javaType != null && !javaType.isAssignableFrom(cls) && !cls.isArray())
             return javaType;

> Extended types in array incorrectly serialised as base type
> -----------------------------------------------------------
>          Key: AXIS-2267
>          URL:
>      Project: Apache Axis
>         Type: Bug
>   Components: Serialization/Deserialization
>  Environment: All: Java logic error
>     Reporter: Clive Brettingham-Moore

> (Version was unknown as 1.3 doesn't appear to be listed, not tagged in CVS either), but
this is using the 1.3 version downloaded from the site.
> Almost put this as a comment on AXIS-2098 or AXIS-2103 but since 1.3 seems to be released
I've made a seperate issue
> Basically I have an application that uses an array field (derived from xsd:sequence in
wsdl) of an abstract base type, where clients submit mixed array of subtypes (in this case
it is payments - so you have the abstract payment type and subtypes for cash, cheque ect).
> The new type handling  (SerialisationContest.getActualJavaClass simply defers to the
specified class ultimately sourced from the array type) simply picks up the serialiser for
the abstract type, instead of the actual element type.
> Since I'm not actually sure of the precise objectives of getActualJavaClass I haven't
attempted a patch, but for my purposes simply checking for class extension would be sufficient
(go with the value's class if it is a subclass of the declared class); avoiding abstract classes
is also a good idea.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message