KDSoap icon indicating copy to clipboard operation
KDSoap copied to clipboard

kdwsdl2cpp: Type/name collisions in nested complexTypes

Open hkaelber opened this issue 8 years ago • 2 comments

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] https://github.com/hkaelber/KDSoap/commit/9913e80031dc80009aaaf922ddd03b091438d5a8

hkaelber avatar May 16 '16 11:05 hkaelber

Hello, sorry for the delay in my reply.

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

dfaure avatar Aug 16 '16 10:08 dfaure

Pull request for simple fix: https://github.com/KDAB/KDSoap/pull/91

Thanks, Holger

hkaelber avatar Oct 18 '16 09:10 hkaelber