Generated ADB code fails on omitted scalar minOccurs=0 elements and recursive 
data types
----------------------------------------------------------------------------------------

         Key: AXIS2-608
         URL: http://issues.apache.org/jira/browse/AXIS2-608
     Project: Apache Axis 2.0 (Axis2)
        Type: Bug

  Components: databinding  
    Versions: 1.0    
 Environment: All
    Reporter: Chuck Williams


The patches I submitted previously (AXIS2-523) to fix various cases of 
minOccurs=0 and recusive data types have been applied in 1.0 RC2 only for 
elements whose types are choice particles.  The underlying problems remain in 
all other cases.

One case of minOccurs=0 that fails is for an omitted scalar element 
(maxOccurs=1).  Consider a simple string-valued element S, and a element C that 
contains S with minOccurs=0.  The Factory.parse() method for C generates code 
to parse S that creates a SimpleElementReaderStateMachine with 
setElementNameToTest() S and then calls it.  But there is no S, so the state 
machine fails.

An example of a recusive data type problem occurs when an element E contains an 
array-valued sub-element also named E.  The parser for the outer E leaves the 
reader positioned at its own start element and then proceeds to search for the 
array by scanning forward looking for the first <E>.  It find itself and not 
the inner E!

The patch resolves this issue and a set of related issues by creating a loop 
invariant for the reader position.  Specifically, the reader is always after 
the end element of the prior element (or initially after the outer start 
element) when it seeks to parse an inner element.  I don't believe the code 
generator can ever parse correctly without having the reader position be a loop 
invariant.  This is why getElementTextProperly() is essential -- because 
getElementText() itself fails to position the reader properly in some cases and 
it is unfortunately now in commons, as documented in the comment in 
ADBBeanTemplate.xsl.

I was able to resolve these issues by using in all cases the template that RC2 
calls out as a special case for choice particles, i.e., by simply deleting the 
altnerative template.  Perhaps there are issues with this template that caused 
it to be called out specially and used only for <choice> particles, but I do 
not know what they are.  I have a complex application that uses all of these 
wsdl features and more that is working perfectly with this template.

All axis2 tests pass with this template, but only after fixing a bug in one 
test that is related to the issues here (PopulateMinOccurs0Test failed when an 
omitted MinOccurs=0 parameter was actually missing).

The attached patch against modules/codegen fixes the issues in both 
ADBBeanTemplate.xsl and PopulateMinOccurs0Test.java.  This patch also contains 
the patch at AXIS-607.



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

Reply via email to