[
http://issues.apache.org/jira/browse/AXIS-2267?page=comments#action_12357901 ]
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/SerializationContext.java
===================================================================
--- Axis/src/org/apache/axis/encoding/SerializationContext.java (revision
345250)
+++ Axis/src/org/apache/axis/encoding/SerializationContext.java (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: http://issues.apache.org/jira/browse/AXIS-2267
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
