[ http://issues.apache.org/jira/browse/AXIS-2267?page=all ]
Davanum Srinivas resolved AXIS-2267:
------------------------------------
Resolution: Fixed
check in the fix.
thanks,
dims
> 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
