axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nadir amra (JIRA)" <axis-c-...@ws.apache.org>
Subject [jira] Closed: (AXISCPP-960) Inconsistent generated APIs when processing WSDLs with xsd:all, xsd:choice and xsd:sequence
Date Wed, 03 Jan 2007 05:03:27 GMT

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

nadir amra closed AXISCPP-960.
------------------------------

       Resolution: Fixed
    Fix Version/s: current (nightly)

Revamped code so now things are simpler than it was before. 

The generated code is now consistent.  As far as determining whether something has been set,
since choice elements are pointers, I would think simply testing if non-null would be sufficient.
 If not, please open a seperate issue. 

> Inconsistent generated APIs when processing WSDLs with xsd:all, xsd:choice and xsd:sequence
> -------------------------------------------------------------------------------------------
>
>                 Key: AXISCPP-960
>                 URL: https://issues.apache.org/jira/browse/AXISCPP-960
>             Project: Axis-C++
>          Issue Type: Bug
>          Components: WSDL processing - Doc, WSDL processing - RPC
>    Affects Versions: current (nightly)
>            Reporter: Adrian Dick
>             Fix For: current (nightly)
>
>         Attachments: example.wsdl
>
>
> Currently, WSDL2Ws generates inconsistent APIs for xsd:all, xsd:choice and xsd:sequence
within a WSDL file.
> For example, taking this WSDL snippet:
> <xsd:complexType name="SequenceObject">
>    <xsd:sequence>
>       <xsd:element name="item1" type="xsd:integer"/>
>       <xsd:element name="item2" type="xsd:integer" nillable="true"/>
>    </xsd:sequence>
> </xsd:complexType>
> WSDL2Ws produces the following:
> public:
>    xsd__integer item1;
>    xsd__integer * item2;
>    xsd__integer getitem1();
>    void setitem1(xsd__integer InValue);
>    xsd__integer * getitem2();
>    void setitem2(xsd__integer * pInValue, bool deep = true);
> ...
> Note how item1 is simply an xsd__integer value, while the nillable item2 element is a
pointer to an xsd__integer value.
> If I now take the same WSDL snippet and modify the xsd:sequence to either xsd:all or
xsd:choice, I get WSDL2Ws producing the following:
> public:
>    xsd__integer* item1;
>    xsd__integer* * item2;
>    xsd__integer* getitem1();
>    void setitem1(xsd__integer* InValue, bool deep = true);
>    xsd__integer* * getitem2();
>    void setitem2(xsd__integer* * pInValue, bool deep = true);
> ...
> Note how all elements have been dererefenced, resulting in item1 now being pointer to
xsd__integer value, while item2 becomes pointer-to-pointer to xsd__integer value.
> It is my opinion that the produced APIs should be the same, as the user should only need
to worry about the data without also needing to be aware of how the SOAP message is produced.
> I would also suggest that the code produced for xsd:sequence is the preffered API.
> Obviously, for xsd:choice there is the additional complication that the user needs to
know which of the elements was received, in this case I propose we would provide an API something
like this:
> public:
>    xsd__integer item1;
>    xsd__integer * item2;
>    xsd__integer getitem1();
>    void setitem1(xsd__integer InValue, bool deep = true);
>    /*
>     *  Additional method to test if the element item1 has been set
>     */
>    xsd__boolean isitem1Set();
>     
>    xsd__integer * getitem2();
>    void setitem2(xsd__integer * pInValue, bool deep = true);
>    /*
>     *  Additional method to test if the element item2 has been set
>     */
>    xsd__boolean isitem2Set(); 
>    /* 
>     * Additional method to indicate which element has been set,
>     * choiceEnum is generated with an enumeration list of all elements within choice
>     */
>    choiceEnum whichElementIsSet(); 
> ...
> Obviously, in the above example we could opt to provide either the isSet methods or the
whichElementIsSet method.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
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