[
https://issues.apache.org/jira/browse/AXIS2C-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Mitchell updated AXIS2C-848:
---------------------------------
Attachment: adb_exemplar_type0.c
adb_exemplar_type0.orig.c
adb_exemplar_type0.single.c
The attached adb_exemplar_type0.single.c shows the generated stub when
maxOccurs = 1 for the entity of type any, while adb_exemplar_type0.orig.c shows
the generated stub when maxOccurs = unbounded. As can be seen, for the single
case the code nicely deserializes by detaching the node from the message, and
serializes by converting the node to a string. (Admittedly expecting and
adding an "extraElement" wrapper around the node, as discussed in AXIS2C-843.)
The attached adb_exemplar_type0.c illustrates the changes in the generated stub
to treat the object as an array of axiom_node_t pointers. In particular:
(1) the deserialize loop to handle the multiple items in the sequence must grab
the next element before detaching this node from the message.
(2) the detached element must now be added to the array, instead of returned as
the entire property.
(3) the serialize loop needs to convert the node to a string, write the string
to the stream, and free the string (something currently overlooked in the
single any code).
(4) the set_extraElement_at routine should do an axiom_node_free_tree on the
element being replaced.
(5) the reset_extraElement routine should do an axiom_node_free_tree on each
existing element (something currently overlooked in the single any code).
(6) the set_extraElement_nil_at routine should do an axiom_node_free_tree on
the element being replaced
In addition, the code reflects corrections to the following issues:
(7) the set_extraElement routine should check for the pointer being null before
asking for the size of the array pointed to.
(8) the set_extraElement_at routine should check if the
axutil_array_list_create succeeded before using the pointer.
(9) the reset_extraElement routine should clear the property_extraElement
pointer after freeing the array.
I have exercised the deserialize side of this illustration code in an
application, but I've not yet exercised the serialize side.
> Generated stub for unbounded sequence of type any does not pass any elements
> to client
> --------------------------------------------------------------------------------------
>
> Key: AXIS2C-848
> URL: https://issues.apache.org/jira/browse/AXIS2C-848
> Project: Axis2-C
> Issue Type: Bug
> Components: code generation
> Affects Versions: Current (Nightly)
> Environment: Windows XP, Visual Studio 2005, guththila parser,
> libcurl, using WSDL2C from nightly build of 12/19/07
> Reporter: Bill Mitchell
> Attachments: adb_exemplar_type0.c, adb_exemplar_type0.orig.c,
> adb_exemplar_type0.single.c, unrolled.wsdl
>
>
> Where a complexType is defined as an unbounded sequence of type any, as in
> the wsdl fragment below, the generated stub implements no code to handle the
> elements themselves, with the comment that it is "imposible to handle the
> request type - so please do it manually". Yet, for the same sequence with a
> maxOccurs = 1, the generated stub is perfectly willing to return the single
> element of type any in a property of type axiom_node_t *, by detaching the
> node from the response document and making it a property of the stub object.
> It would be useful and reasonable in the case of multiple any items to return
> an array of axiom_node_t*, by detaching each from the response message, as is
> done in the case of a single any element.
> <element name="getExemplarResponse">
> <complexType>
> <complexContent>
> <restriction base="anyType">
> <sequence>
> <element name="exemplar" minOccurs="1"
> maxOccurs="1">
> <complexType>
> <sequence>
> <any namespace="##local"
> minOccurs="1" maxOccurs="unbounded"/>
> </sequence>
> <attribute name="handle"
> type="string" use="required"/>
> </complexType>
> </element>
> </sequence>
> <attribute name="responseCode" type="integer"
> use="optional" default="0"/>
> <attribute name="responseMessage" type="string"
> use="optional"/>
> <attribute name="supportedMethods"
> type="fw:MethodListType" use="optional"/>
> </restriction>
> </complexContent>
> </complexType>
> </element>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
