axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dimuthu Gamage (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AXIS2C-843) Generated deserialize method does not handle complex type containing sequence of type any
Date Tue, 18 Dec 2007 20:11:43 GMT

    [ https://issues.apache.org/jira/browse/AXIS2C-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552878
] 

Dimuthu Gamage commented on AXIS2C-843:
---------------------------------------

Hi Bill,

1. The name 'extraElement' qname comparison is wrong as you mentioned. It should be corrected
both in serialization and deserialization.

2. Although you say 'any' should represent array of axiom_node_t I m not sure whether it is
the rule. Since there is maxOccurs=1 it will not be an array. (It would have been an array
if maxOccurs>1 or even 'unbounded'.

And I saw java generated code also have following function skeleton.

org.apache.axiom.om.OMElement getExtraElement()
setExtraElement(org.apache.axiom.om.OMElement param)

which is not an array. So I think the current code is correct in this case. Just let me know
if this theory is wrong.

Thanks
Dimuthu

> Generated deserialize method does not handle complex type containing sequence of type
any
> -----------------------------------------------------------------------------------------
>
>                 Key: AXIS2C-843
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-843
>             Project: Axis2-C
>          Issue Type: Bug
>          Components: code generation
>    Affects Versions: 1.1.0
>         Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl
>            Reporter: Bill Mitchell
>         Attachments: adb_exemplar_type0.new.c, adb_exemplar_type0.orig.c, unrolled.wsdl
>
>
> When WSDL2C generates a stub for the following response message description, it constructs
a stub for entity exemplar.  For this entity, it defines a single property of type axiom_node_t,
the deserialize routine parses only the first of the "any" elements, and ignores the remainder.
 The second issue is that it parses the "any" entity only if its name is "extraElement", which
is not very useful as it has some name, unknown at compilation time, but which is not likely
to be "extraElement".   
>             <element name="getExemplarResponse">
>                 <complexType>
>                     <complexContent>
>                         <restriction base="anyType">
>                             <sequence>
>                                 <element name="exemplar">
>                                     <complexType>
>                                         <sequence>
>                                             <any namespace="##local" minOccurs="1"
maxOccurs="1"/>
>                                         </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>
> My suggestion is that the comparison for the QName "extraElement" should be removed,
and the property of extraElement should be an array of axiom_node_t representing all of the
sequence of "any" entities.  This impacts the deserialize and serialize routines, and the
resetter method to avoid the potential memory leak.  I've seen such code generated for a sequence
of elements of a simple type, so it should not be too hard to generate the same code here
in a complexType.  

-- 
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: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Mime
View raw message