axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 24576] New: - WSDL2Java gens incorrect classes for nested element definition
Date Mon, 10 Nov 2003 18:40:55 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24576>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24576

WSDL2Java gens incorrect classes for nested element definition

           Summary: WSDL2Java gens incorrect classes for nested element
                    definition
           Product: Axis
           Version: current (nightly)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: WSDL processing
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: kbrichan@comcast.net


WSDL2Java generates incorrect classes for a WSDL containing a nested element 
definition having the same name as a top-level element definition.

A simplified, skinnied-down example:

<element name='x'>
  <complexType>
    <sequence>
      <element name='a' type='int'/>
    </sequence>
  </complexType>
</element>
<element name='y'>
  <complexType>
    <sequence>
      <element ref='tns:x'/>
    </sequence>
  </complexType>
</element>
<element name='z'>
  <complexType>
    <sequence>
      <element name='x'>
        <complexType>
          <sequence>
            <element name='b' type='int'/>
          </sequence>
        </complexType>
      </element>
    </sequence>
  </complexType>
</element>

What should get generated is a class for:
1. the top-level x, which contains a
2. the top-level y, which contains top-level x
3. the top-level z, which contains the nested z_x
4. the nested z_x, which contains b

Instead, what gets generated is:
1. ok
2. the top-level y, which contains nested z_x
3. ok
4. ok

Reason:
Utils.getNodeNameQName returns "x" for both the top-level x and the nested z_x 
because it sees the name attribute and looks no further. But the return for the 
complexType inside the nested z_x accurately returns >z>x. If getNodeNameQName 
is changed to return "x" for the top-level x and z>x for the nested z_x, 
everything works.

Mime
View raw message