[ http://issues.apache.org/jira/browse/AXIS2-608?page=all ]
Chuck Williams updated AXIS2-608:
---------------------------------
Attachment: PopulateComplexMinOccurs0Test.java
Second of the two changed MinOccurs tests -- these two source files can be used
in lieu of codegen.test.patch.
> 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
> Assignee: Ajith Harshana Ranabahu
> Attachments: ADBBeanTemplate.xsl, PopulateComplexMinOccurs0Test.java,
> PopulateMinOccurs0Test.java, codegen.patch, codegen.src.patch,
> codegen.test.patch
>
> 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
