Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Date: 13 Nov 2003 08:32:05 -0000
Message-ID: <20031113083205.12741.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: axis-dev@ws.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 24576]  -
    WSDL2Java gens incorrect classes for nested element definition

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


------- Additional Comments From iasandcb@apache-korea.org  2003-11-13 08:32 -------
First of all, thank you for your response with Korean greeting, which moved me 
a lot. :-)

As you pointed out, I made change to JavaBeanWriter and it worked fine with 
neat field names. 
In addition, the above experimental patch on Utils has a bug for multiply 
nested types. For example,

    <xsd:element name="ias_request" type="s0:ias_request"/>
    <xsd:complexType name="ias_request">
    	<xsd:sequence>
	    <xsd:element name="ias_info" minOccurs="0" maxOccurs="unbounded">
	      <xsd:complexType>
		<xsd:sequence>
	    	    <xsd:element name="name" type="xsd:string"/>
		    <xsd:element name="age" type="xsd:int"/>
		</xsd:sequence>
		<xsd:attribute name="reality" type="xsd:boolean" 
use="required"/>
	      </xsd:complexType>
	    </xsd:element>
	</xsd:sequence>
    </xsd:complexType>

the local part of "ias_info" element is "ias_request>ias_info", and
the local part of "ias_info" element's type should be ">ias_request>ias_info", 
but
the current axis with the patch shows "ias_request>>ias_request>ias_info".

(Please keep in mind that the whole interpretation is based on JSR-921.)

After fixing this bug, I learned that there were quite a lot of codes and test 
cases that the change affected.

Let me introduce them from test cases to source codes.

As for test case,

In DataServiceTestCase
_GetTitleAuthorsResponse_GetTitleAuthorsResult
->
__GetTitleAuthorsResponse_GetTitleAuthorsResult

In Round4XSDTestSoapImpl and Round4XSDTestTestCase
_echoAnyElementResponse_return 
->
__echoAnyElementResponse_return
_echoAnyElement_inputAny
->
__echoAnyElement_inputAny

In Qualify_ServiceTestCase and Qualify_BindingImpl
_FormOverrideResponse_response
->
__FormOverrideResponse_response
_FormOverride_complex
->
__FormOverride_complex

In ComprehensiveTypes.wsdl
        <!-- Test for nested defined complexType  -->
        <xsd:element name="a" type="xsd:short" />
        <xsd:complexType name="b">
          <xsd:sequence>
            <xsd:complexType name="a">
              <xsd:sequence>
                <xsd:element name="c" type="xsd:int" />
              </xsd:sequence>
            </xsd:complexType>
            <xsd:element name="d" type="typens2:a" />
          </xsd:sequence>
        </xsd:complexType>
->
            <xsd:complexType name="a">
              <xsd:sequence>
                <xsd:element name="c" type="xsd:int" />
              </xsd:sequence>
            </xsd:complexType>
        <xsd:complexType name="b">
          <xsd:sequence>
            <xsd:element name="d" type="typens2:a" />
          </xsd:sequence>
        </xsd:complexType>

(The reasons is, from http://www.w3.org/TR/2000/WD-xmlschema-1-
20000407/#declare-contentModel
, the latest spec of http://www.w3.org/1999/XMLSchema, <xsd:element> is not 
allowed for content of <xsd:sequence>.
I guess the case attempted to show a nested element is typed to a nested 
defined complexType, but the XML Schema syntax doesn't enable that.)

VerifyTestCase
ComplexWComplex_stock_quote
->
_complexWComplex_stock_quote

As for source code,

In wsdl.toJava package
JavaDeployWriter
JavaBeanWriter
JavaBeanHelperWriter
JavaStubWriter
JavaSkelWriter
Utils

In wsdl.symbolTable package
SymbolTable
Utils

need changes. Basically JavaXxxWriters uses Utils.xxxQNameWithLastLocalPart to 
get along with the then-existing Axis' SOAP message composition.

I qualified all those modifications with all-tests and happily had O.K as a 
result. 

I expect feedback about supporting this new concept of expressing elements' 
QName following JSR-921.

Thanks,

Ias