axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas (JIRA)" <>
Subject [jira] Resolved: (AXIS-2011) Multi Dimensional Array Serialization
Date Mon, 30 May 2005 16:59:56 GMT
     [ ]
Davanum Srinivas resolved AXIS-2011:

    Resolution: Fixed

Already fixed. Right Guillaume?

-- dims

> Multi Dimensional Array Serialization
> -------------------------------------
>          Key: AXIS-2011
>          URL:
>      Project: Axis
>         Type: Improvement
>   Components: Serialization/Deserialization, Deployment / Registries
>     Versions: 1.2
>  Environment: JOnAS 4.4
>     Reporter: Guillaume Sauthier
>     Assignee: Guillaume Sauthier
>      Fix For: 1.2.1
>  Attachments: axis-arrayMapping.patch, axis-src.jar, axis-test.jar
> Actually the test case test.wsdl.marshall is broken because Axis do not serialize 2D
arrays as expected.
> See for reference.
> We are expecting a correct SOAP Message formed like this :
> soap:Body
>  ns1:myOperation
>   return
>    return soapenc:arraytype="xsd:string[][2]" xsi:type="soapenc:Array"
>     return soapenc:arraytype="xsd:string[2]" xsi:type="soapenc:Array"
>      return xsi:type="xsd:string" [Value1]
>      return xsi:type="xsd:string" []
>      return xsi:type="xsd:string" xsi:nil="true"
> [...]
> Instead, we have the following :
> soap:Body
>  ns1:myOperation
>   return
>    return soapenc:arraytype="ns:ArrayOfstring[][2]" xsi:type="soapenc:Array"
>     return soapenc:arraytype="xsd:string[2]" xsi:type="soapenc:Array"
>      return xsi:type="xsd:string" [Value1]
>      return xsi:type="xsd:string" []
>      return xsi:type="ns:ArrayOfArrayOfstring" xsi:nil="true"
> [...]
> Points to notice :
> A. the first arrayType has a wrong xml type (expecting most inner non array type xsd:string
in place of ns:ArrayOfstring)
> B. the first arrayType has a right dims ([][2]) : 2D array with 2 elements for the first
> C. last element of the array has a wrong xsi:type ! I don't know where it comes from
but its wrong, indeed :)
> The first thing I tried to change the xsi:type (C) was to lookup the xml type from the
(most inner non array )Java type we retrieve. Problem with this approach : I can't exactly
control if I will get an xsd:string or soapenc:string. For my case, I was waiting an xsd:string
and the TypeMapping gives me a soapenc:string. Grrr !
> Looking deeper in ArraySerializer.serialize(), we can see that this serializer is not
"symetrical" (for java type and xml type) : we can go several levels deep when searching for
the most inner non array java type, but we're stuck to the itemType (only 1 level deep) retrieved
from SerializationContext for xml types!
> My idea is to allow searching in xml types too. If we have for each ArraySerializer the
wanted innerType, we can get the mapped serializer. If the retrieved serializer is an ArraySerilalizer,
we can go one step further, ...
> So with this, we're symetrical (we go deeper for the xml AND java types in the same time).
> Notice that's more time consumming, because we search TypeMapping very often !
> Now, how to give these metadatas to the Engine ? In the wsdd, indeed !
> So now, we have a new element arrayMapping element that allow us to specify the innerType
for an ArraySerializer !
> To be complete, I made some changes too in JavaDeployWriter, to write up the arrayMapping
element when an ArraySerializerFactory has to be used.
> Important : This is only for review (Glen/Tom ?) !! The code attached to this report
is neither clean nor complete :
> - innerName attribute is not used, could be usefull ?
> - to limitate the number of impacted files, a lot of Constants are inside WSDDArrAyMapping,
should go in WSDDContstants.
> - at this time, arrayMapping is only understand if contained in a service element ! We
should add for each TypeMappingContainer subclasses...
> - WSDDArrayMapping can be improved with error message (when trying to set ser/deser other
than ArraySerFactory...)
> - maybe we can add some NPE checks :)
> Thanks for your comments/suggestions !
> --Guillaume

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