[
http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12375969 ]
Chuck Williams commented on AXIS2-608:
--------------------------------------
Hi Ajith,
That's a good point. I suppose one case where sequence order would be
particularly important is if there were two different inner properties with the
same element name. I don't have any wsdl like that as so have not hit that
problem. So the question is how best to preserve the order for sequence and
still handle cases like omitted minOccurs=0 and recursive data type (inner
element with same name as outer element).
One way to do this would be to start with the schema for choice, which seems to
handle everything except sequence order, and then to modify the generated code
in the sequence case slightly. Omit the outer while (!reader.isEndElement())
loop and instead generate the code for each of the properties in order.
Between each property and the next, there needs to be code like this:
while (!reader.isStartElement() && !reader.isEndElement())
reader.next();
The code to parse each property woudl still be wrapped in:
<xsl:if test="position()>1">else</xsl:if> if
("<xsl:value-of select="$propertyName"/>".equals(reader.getLocalName())){
but for properties that must be present (minOccurs > 0) there would be an else
to throw an exception. For minOccurs=0 properties, this else woudl simply be
omitted.
I haven't tried it, but expect that would handle all cases. It woudl probably
be easier to have this be one template with suitable <xsl:when> elements to
distringuish between the sequence and choice cases.
I'm more familiar with this template than the other -- the alternative fix
would of course be to address these same issues in the other template.
I hope this is deemed improtant enough to be a must-fix for 1.0? Without a fix
to this issue, axis2 generated ADB code fails on so basic wsdl constructs that
are on the supported feature list (e.g., minOccurs=0 and recursive data types).
> 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
> 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
