You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We encountered some problems using kdsoap for accessing ciscos axl soap interface [1] via kdwsdl2cpp generated classes. The used schema [2] defines tons of nested complex-types within elements having the same name, while the structure of the complexTypes are different.
Take as an example the <xsd:element name='return'> that is used in many places as container for API-responses:
cat AXLSoap.xsd | egrep "name=['"]return['"]" | wc -l
292
Using kdwsdl2cpp as is, this leads to a single generated type XSD__Return defined following the first occurence of <xsd:element name='return'> within the xsd, which is nested in <xsd:complexType name='GetSipProfileRes'>. Now if you want to evaluate other responses that use return you will only be able to access a XSD__Return with the wrong members (those of 'GetSipProfileRes').
The quick-fix in commit [3] resolves the issue for me. It simply checks whether a complexType of a given name already exists and increments a numeric postfix until we have a new type-name.
This is not an optimal solution because thus also different classes are generated for complexTypes that are structurally identic, which is not wrong, but further bloats the generated code, in my case:
I agree with your analysis and solutions (the quick one in the mentioned commit and the idea for a better one).
What's missing is a unittest triggering this case. I tested your patch, and none of the WSDL/XSD files under unittests led to the qDebug() being shown. Can you either modify the WSDL in e.g. unittest/wsdl_document so that it hits this issue, or send me the full XSD file, assuming I can make it public (by adding it to a kdsoap unittest) ?
We encountered some problems using kdsoap for accessing ciscos axl soap interface [1] via kdwsdl2cpp generated classes. The used schema [2] defines tons of nested complex-types within elements having the same name, while the structure of the complexTypes are different.
Take as an example the <xsd:element name='return'> that is used in many places as container for API-responses:
cat AXLSoap.xsd | egrep "name=['"]return['"]" | wc -l
292
Using kdwsdl2cpp as is, this leads to a single generated type XSD__Return defined following the first occurence of <xsd:element name='return'> within the xsd, which is nested in <xsd:complexType name='GetSipProfileRes'>. Now if you want to evaluate other responses that use return you will only be able to access a XSD__Return with the wrong members (those of 'GetSipProfileRes').
The quick-fix in commit [3] resolves the issue for me. It simply checks whether a complexType of a given name already exists and increments a numeric postfix until we have a new type-name.
This is not an optimal solution because thus also different classes are generated for complexTypes that are structurally identic, which is not wrong, but further bloats the generated code, in my case:
Before:
Converting 141 simple types
Converting 1563 complex types
18M wsdl_AXLAPI.cpp
3.0M wsdl_AXLAPI.h
After:
Converting 145 simple types
Converting 2420 complex types
21M wsdl_AXLAPI.cpp-new
3.6M wsdl_AXLAPI.h-new
A better solution could check for complete structural identity (via a ComplexType::operator==() or so) instead of typename equality.
What do you think?
Thanks,
Holger
[1] https://developer.cisco.com/site/axl/
[2] https://developer.cisco.com/media/axl-schema-11-0/AXLSoap.xsd
[3] hkaelber@9913e80
The text was updated successfully, but these errors were encountered: