Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Message-ID: <18084210.1149245011039.JavaMail.jira@brutus>
Date: Fri, 2 Jun 2006 10:43:31 +0000 (GMT+00:00)
From: "Ajith Harshana Ranabahu (JIRA)" <jira@apache.org>
To: axis-dev@ws.apache.org
Subject: [jira] Resolved: (AXIS2-768) WSDL2Java (via Eclipse plugin)
 generates code with a bug
In-Reply-To: <29475191.1148606875759.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/AXIS2-768?page=all ]
     
Ajith Harshana Ranabahu resolved AXIS2-768:
-------------------------------------------

    Resolution: Fixed

Peter has verified that this issue is solved and hence I'm marking this issue as solved.  
As for replacing the template, you did the right thing :)

> WSDL2Java (via Eclipse plugin) generates code with a bug
> --------------------------------------------------------
>
>          Key: AXIS2-768
>          URL: http://issues.apache.org/jira/browse/AXIS2-768
>      Project: Apache Axis 2.0 (Axis2)
>         Type: Bug

>  Environment: Windows XP Pro, SP2
> Axis2 (version 1.0), Eclipse plugin version 1.0
> Eclipse 3.1.2
>     Reporter: Peter Smith
>     Assignee: Ajith Harshana Ranabahu
>  Attachments: ADBBeanTemplate.xsl.patch
>
> [Still new to web services.]
> I generated some client code, sync style only, with adb binding. 
> Error occurs when running client (service-consuming) code generated by the Eclipse plugin:
>     "java.lang.RuntimeException: java.lang.RuntimeException: Unexpected subelement StadiumInfo"
> WSDL location here ( http://www.xmethods.com/ve2/ViewListing.po;jsessionid=WKLq4DIo6x-jHNRE5dafpPhj(QHyMHiRM)?key=uuid:2ED51A61-68E6-90ED-45B7-E318C299C8C5 ), or here ( http://tinyurl.com/ltook ).
> The xml being consumed looks like this (snippet):
> ==========================================
>   <soap:Body>
>     <m:AllGamesResponse xmlns:m="http://www.dataaccess.nl/wk2006">
>       <m:AllGamesResult>
>         <m:tGamesInfo>
>           <m:sDescription>Round 1</m:sDescription>
>           <m:dPlayDate>2006-06-09</m:dPlayDate>
>           <m:tPlayTime>18:00:00</m:tPlayTime>
>           <m:StadiumInfo>
>             <m:sStadiumName>FIFA World Cup Stadium Munich</m:sStadiumName>
>             <m:iSeatsCapacity>59416</m:iSeatsCapacity>
>             <m:sCityName>Munich</m:sCityName>
>           </m:StadiumInfo>
>           <m:Team1>
>             <m:sName>Germany</m:sName>
>             <m:sCountryFlag>http://www.dataaccess.nl/wk2006/flags/GERMANY_.jpg</m:sCountryFlag>
>           </m:Team1>
>           <m:Team2>
>             <m:sName>Costa Rica</m:sName>
>             <m:sCountryFlag>http://www.dataaccess.nl/wk2006/flags/COSTA___.jpg</m:sCountryFlag>
>           </m:Team2>
>           <m:sResult>U</m:sResult>
>           <m:sScore />
>           <m:iYellowCards>0</m:iYellowCards>
>           ...
> ==========================================
> Things go well until 'Team1' (the second complextype) is about to be processed, at which point the 'unexpected subelement' runtime exception occurs. 
> I'll dive in and take a gander at what's going on - please forgive. It seems the generated code is unaware of the nested/complex nature of the 'StadiumInfo' element as relates to advancing to the next starting element, so when it tries to 'climb out/up' the tree to find the next sibling, it doesn't make it. So, instead of being positioned at the closing 'StadiumInfo' tag upon returning from parsing the 'StadiumInfo' element, it is somewhere a bit deeper - maybe at the whitespace just before the closing 'StadiumInfo' tag. The pre-ordained sequential processing means that the next element sought, in our case 'Team1', will not be found and the RuntimeException occurs.
> I was able to get past this error in a couple of ways:
> 1) Adding a couple more 'reader.next();' statements just above the test looking for the start of the next element. These statements must be inserted after processing all complex types.
> 2) Changing the 'reader.next()' paradigm into one that doesn't pay any attention to depth level or complex types, but just looks at every 'next()' element until it satisfies the conditions we're looking for - that is, that the next starting element we find has the name we want.
> Here is the generated code for a typical (simple/not-complex) element. 
>                 // do certain number of 'reader.next()' calls to skip whitespace/comments/etc., then hope you're in the right place in the tree (my comment)
>                 if (reader.isStartElement() &&
>                         new javax.xml.namespace.QName(
>                             "http://www.dataaccess.nl/wk2006", "sDescription").equals(
>                             reader.getName())) {
>                     // process the current element (my comment)
>                     java.lang.String content = getElementTextProperly(reader);
>                     object.setSDescription(org.apache.axis2.databinding.utils.ConverterUtil.convertTostring(
>                             content));
> And here is another way that I hacked the generated code to get it going:
>                 // what is the qualified name of the next element we're looking for? (my comment)
>                 javax.xml.namespace.QName qname = new javax.xml.namespace.QName("http://www.dataaccess.nl/wk2006", "sDescription");
>                 // keep moving ahead until you find the element you're looking for (my comment)
>                 while ( ! ( reader.isStartElement() && qname.equals(reader.getName())) ){
>                 		reader.next();
>                 }
>                 // process the current element (my comment)
>                 java.lang.String content = getElementTextProperly(reader);
>                 object.setSDescription(org.apache.axis2.databinding.utils.ConverterUtil.convertTostring(
>                         content));
> That's it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org