[
https://issues.apache.org/jira/browse/AXIS2-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Gourley updated AXIS2-4222:
---------------------------------
Attachment: ChoiceInfiniteLoop.patch
The issue is that the reader could potentially sit on the same element and
continually try to parse the content into one of the choices. If none of the
choices match (they may or may not throw exceptions during this failure to
match), the reader may not move during any of the parse attempts. I use the
words 'could' and 'may' because I'm not sure whether or not the behaviour may
change depending on the minOccurs values of each element involved in the choice
schema.
I've just attached a patch that throws an ADBException if there are trailing
elements (i.e. no choices completely consumed all of the elements).
The previous patch that was uploaded did not fix the problem for me, but it may
address a different use case.
> Codegen introduces infinite loop in generated code ( while deserealising )
> ---------------------------------------------------------------------------
>
> Key: AXIS2-4222
> URL: https://issues.apache.org/jira/browse/AXIS2-4222
> Project: Axis2
> Issue Type: Bug
> Components: codegen
> Affects Versions: 1.5
> Environment: current codebase from svn
> Reporter: Konstantin Pribluda
> Attachments: axis-4222.patch, ChoiceInfiniteLoop.patch
>
>
> I have following complex type:
> ---------------- snip -------------
> <xs:complexType name="typePRODUCTLINK">
> <xs:sequence>
> <xs:choice>
> <xs:element ref="P_ID"/>
> <xs:element ref="P_NVAG_PID"/>
> </xs:choice>
> <xs:element name="LINK_SORT" minOccurs="0">
> <xs:annotation>
>
> <xs:documentation>(Sortierung)</xs:documentation>
> </xs:annotation>
> <xs:simpleType>
> <xs:restriction base="typeSORT">
> <xs:totalDigits value="3"/>
> </xs:restriction>
> </xs:simpleType>
> </xs:element>
> </xs:sequence>
> </xs:complexType>
> -------------------- snap ----------------------
> And it produces following while loop:
> ------------------------ snip ---------------
> while(!reader.isEndElement()) {
> if (reader.isStartElement() ){
>
> if (reader.isStartElement() ){
>
>
> object.setTypePRODUCTLINKChoice_type0(censored.TypePRODUCTLINKChoice_type0.Factory.parse(reader));
>
> } // End of if for expected property start
> element
>
> else
>
> if (reader.isStartElement() && new
> javax.xml.namespace.QName("censored","LINK_SORT").equals(reader.getName())){
>
>
> object.setLINK_SORT(censored.LINK_SORT_type1.Factory.parse(reader));
>
> reader.next();
>
> } // End of if for expected property start
> element
>
> } else {
> reader.next();
> }
> } // end of while loop
> --------------------- snap -----------------
> This is obvious, that this while loop never goes for LINK_SORT, and thus
> never terminates
> for such XML snippet:
> ------------------- snip -----------------
> <P_SUBPRODUCT type="FAMILY">
> <P_ID>402322g</P_ID>
> <LINK_SORT>1</LINK_SORT>
> </P_SUBPRODUCT>
> ------------------- snap ----------------
> I was able to identify problem source in ADBBeanTemplateXSL ( from line 2816
> ):
> -----------------snip----------
> <xsl:choose>
> <xsl:when test="$unordered and not($choice
> and $hasParticleType)"> <!-- One property per iteration if unordered -->
> <xsl:if test="position()>1">
> else
> </xsl:if>
> </xsl:when>
> <xsl:otherwise>
> <!-- If sequence, advance to start of
> next property or to end of outer element -->
> while (!reader.isStartElement()
> && !reader.isEndElement()) reader.next();
> </xsl:otherwise>
> </xsl:choose>
> -----------------snap---------
> If I manually edit generated beans as if "otherwise" was choosen, everything
> works as expected.
> So IMHO bug is somewhere in choice condition. ( but unfortunately my limited
> experience with codegen codebase does not allow me to produce a patch at the
> moment,
> though it may change really soon )
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
