You are viewing a plain text version of this content. The canonical link for it is here.
Posted to kandula-dev@ws.apache.org by "Aaron Gourley (JIRA)" <ji...@apache.org> on 2010/09/23 00:04:37 UTC
[jira] Updated: (AXIS2-4222) Codegen introduces infinite loop in
generated code ( while deserealising )
[ 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org