Overview
Artifact ID: | f85ef1c289e65cb17547a31ae040eddb44b48cb1d55b495166853c68bbf7ccf6 |
---|---|
Ticket: | 584bfb772724c1a938f671b8a9ac1d57b2d70f58
WS::Client returns nonsense for abstract types |
User & Date: | oehhar 2018-02-20 21:50:59 |
Changes
- Appended to comment:
<hr /><i>oehhar added on 2018-02-20 21:50:59 UTC:</i><br /> What I understand from [https://www.w3.org/TR/xmlschema-1/#ct-target_namespace], an abstract type should have: * simpleContent * complexContent In our case, it is complex content, but saved as simple type. So this is changed in branch [bug584bfb7727-abstract-type] by commit [6975d0e818]. This results in a complex type definition for tns1:Envelope with the attributes: <verbatim> typeInfo client $service tns1:envelope { definition {} xns tns1 abstract true } </verbatim> The result is still the same. This does not help and there is more work necessary. But here is the log of the WSDL parse of envelope type: <verbatim> Entering parseComplexType Client serviceInfo 1 domNode053DBE0C tns1 Complex Type is tns1:Envelope Abstract type = true Complex Type is tns1:Envelope, middle is annotation Complex Type is tns1:Envelope, middle is complexContent isComplexContent := 1 Content Type is {extension} Calling partList for extension of tns1:Envelope Entering partList Client domNode053DBEBC 1 results tns1 -- for extension base name of extension is {tns1:Geometry} with typeinfo {0 0} Simple type partList for extension of tns1:Envelope is {{}} at end of foreach {tns1:Envelope} with {} Defining tns1:Envelope as Entering ::WS::Utils::ServiceTypeDef Client 1 tns1:Envelope {} tns1 true </verbatim>