[jira] Updated: (AXIS2C-1071) WSDL2C, ADB & xsi:type based deserialization

["Sérgio Gomes (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AXIS2C-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sérgio Gomes updated AXIS2C-1071:
---------------------------------

    Attachment: polymorphism.patch

I've got an initial implementation of a fix to this problem, submitting it below.

Here are some notes.

PROBLEM: In Axis2/C, ADB objects are stripped down to their abstract types when being sent or received in SOAP requests.
SOLUTION: To implement an "extension handler" that is aware of all types, and can pick between them. This is done by:
a) Storing an object's type in the object itself and using that knowledge when serializing (converting to XML) and "free"ing.
b) Reading the xsi:type in incoming XML, and using that to invoke the specific deserialization function (XML to object).

Implementation details:

The code I implemented patches the ADB code generator to generate two new files, axis2_extension_mapper.h/c, that are aware of all extensions and can pick the right type and method to serialize / deserialize. This is done with a different model in the same XSL files.

I added property_Type, so that each struct is aware of its type. This is the correct way of checking which type an object should be cast to, after deserializing (the property is filled by the deserialization method, upon creation of the specific object).

As for changing the serialization / deserialization, I decided to rename the methods in all the objects to *_serialize_obj and *_deserialize_obj, and to keep *_serialize and *_deserialize as wrappers, that call the serialize and deserialize methods in the extension handler module. This module then picks the correct *_serialize_obj or *_deserialize_obj method. These changes were done to minimize number of lines of code changed. 'free' has also been "polymorphed", and "create" is updated to fill in property_Type.

This has been tested on requests and responses, client-side (I haven't really had the chance to test the patch server-side).

Please let me know if you have any comments or suggestions!

> WSDL2C, ADB & xsi:type based deserialization
> --------------------------------------------
>
>                 Key: AXIS2C-1071
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-1071
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: core/addressing
>            Reporter: Sam Meder
>         Attachments: polymorphism.patch
>
>
> I have the problem of having to work with a wsdl interface the makes use of type extensions and xsi:type. For example:
>          <complexType name="VirtualHardware">
>             <complexContent>
>                <extension base="vim25:DynamicData">
>                   <sequence>
>                      <element name="numCPU" type="xsd:int" />
>                      <element name="memoryMB" type="xsd:int" />
>                      <element name="device" type="vim25:VirtualDevice" minOccurs="0" maxOccurs="unbounded" />
>                   </sequence>
>                </extension>
>             </complexContent>
>          </complexType>
> where the VirtualDevice type is extended in various ways to reflect different kind of device types:
>          <complexType name="VirtualController">
>             <complexContent>
>                <extension base="vim25:VirtualDevice">
>                   <sequence>
>                      <element name="busNumber" type="xsd:int" />
>                      <element name="device" type="xsd:int" minOccurs="0" maxOccurs="unbounded" />
>                   </sequence>
>                </extension>
>             </complexContent>
>          </complexType>
> The issue I am running into is that WSDL2C does not seem to support this kind of xsi:type based type serialization/deserialization (which admittedly fits really poorly with a non-object oriented language like C). You could probably make it work by storing type information in the generated structs, combined with a type registry.
> Any suggestions on workarounds other than using the XML model?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.