Return-Path: Delivered-To: apmail-ws-axis-c-dev-archive@www.apache.org Received: (qmail 93383 invoked from network); 3 Jan 2007 05:03:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Jan 2007 05:03:49 -0000 Received: (qmail 27417 invoked by uid 500); 3 Jan 2007 05:03:55 -0000 Delivered-To: apmail-ws-axis-c-dev-archive@ws.apache.org Received: (qmail 27404 invoked by uid 500); 3 Jan 2007 05:03:55 -0000 Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: "Apache AXIS C Developers List" Reply-To: "Apache AXIS C Developers List" Delivered-To: mailing list axis-c-dev@ws.apache.org Received: (qmail 27393 invoked by uid 99); 3 Jan 2007 05:03:55 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Jan 2007 21:03:55 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Jan 2007 21:03:48 -0800 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id A16B07142FB for ; Tue, 2 Jan 2007 21:03:27 -0800 (PST) Message-ID: <18086891.1167800607658.JavaMail.jira@brutus> Date: Tue, 2 Jan 2007 21:03:27 -0800 (PST) From: "nadir amra (JIRA)" To: axis-c-dev@ws.apache.org Subject: [jira] Closed: (AXISCPP-960) Inconsistent generated APIs when processing WSDLs with xsd:all, xsd:choice and xsd:sequence In-Reply-To: <1053530644.1143707369977.JavaMail.jira@ajax> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ 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: > > > > > > > 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