[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376731 ]
Ajith Harshana Ranabahu commented on AXIS2-608: ----------------------------------------------- hmm... This sets me back nearly one months work but hey even Brooks said "be ready to throw one away" :). I'll revert back to the choice template and forget about the sequence for a while. > 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: codegen.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
