[ http://issues.apache.org/jira/browse/AXISCPP-960?page=all ]
Adrian Dick updated AXISCPP-960:
--------------------------------
Attachment: example.wsdl
I have produced this simple WSDL containing otherwise identical examples of
using xsd:all, xsd:choice and xsd:sequence which can be used for testing this
issue.
> Inconsistent generated APIs when processing WSDLs with xsd:all, xsd:choice
> and xsd:sequence
> -------------------------------------------------------------------------------------------
>
> Key: AXISCPP-960
> URL: http://issues.apache.org/jira/browse/AXISCPP-960
> Project: Axis-C++
> Type: Bug
> Components: WSDL processing - Doc, WSDL processing - RPC
> Versions: current (nightly)
> Reporter: Adrian Dick
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
