You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Chuck Williams (JIRA)" <ji...@apache.org> on 2006/04/24 07:17:05 UTC
[jira] Created: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements 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
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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Sanjiva Weerawarana (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376389 ]
Sanjiva Weerawarana commented on AXIS2-608:
-------------------------------------------
Is there any chance you can provide an improved patch that fixes both sides? That would be ideal.
If not I think I agree with you that the order constraint is less important than minOccurs=0.
> 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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Ajith Harshana Ranabahu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376390 ]
Ajith Harshana Ranabahu commented on AXIS2-608:
-----------------------------------------------
Hi Chuck,
RC3 does not inlcude a fix for this but I assure you that this is deemed important and will be fixed for 1.0. I'll assign this issue to myself.
BTW would you settle for a change where the state machines are slightly modified to handle the minOccurs =0 case?
> 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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Ajith Harshana Ranabahu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12375956 ]
Ajith Harshana Ranabahu commented on AXIS2-608:
-----------------------------------------------
Hi Chuck,
The reason for the alternative template (one used for sequence) is that for a sequence the order needs to be checked also. The template for choice works fine but the problem is that even when the sequence is out, it works! That is why the templates are special cased - a sequence preserving template and a sequence non preserving template for <choice> and <all>
I' m inclined to think that parsing an XML with knowledge of the order is also important
> 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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Ajith Harshana Ranabahu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376706 ]
Ajith Harshana Ranabahu commented on AXIS2-608:
-----------------------------------------------
Seems the changes we did to the template and the state machines to solve the minOccurs=0 case has also solved the recursive datatypes case.
Please have a look at the new testcase i've checked in (org.apache.axis2.schema.populate.other.PopulateRecursiveTest in the codegen module) and see whether it is a reasonable test case to check the issue . If so let me know whether we can close this issue :)
> 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
[jira] Reopened: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=all ]
Davanum Srinivas reopened AXIS2-608:
------------------------------------
> 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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Chuck Williams (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12375977 ]
Chuck Williams commented on AXIS2-608:
--------------------------------------
Erratum:
The code to parse each property would still be wrapped in:
if ("<xsl:value-of select="$propertyName"/>".equals(reader.getLocalName())){
No <xsl:if test="position()>1">else</xsl:if> before the if in the <sequence> case! There still is an else statement after the if statement to throw an exception for madatory properties (i.e., minOccurs>0).
> 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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Ajith Harshana Ranabahu (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Chuck Williams (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=all ]
Chuck Williams updated AXIS2-608:
---------------------------------
Attachment: codegen.test.patch
codegen.test.patch provides the corrections to the two PopulateMinOccurs tests.
> 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, 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
[jira] Updated: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Chuck Williams (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=all ]
Chuck Williams updated AXIS2-608:
---------------------------------
Attachment: ADBBeanTemplate.xsl
Modifed source file that can be used in lieu of codgen.src.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, 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
[jira] Resolved: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=all ]
Davanum Srinivas resolved AXIS2-608:
------------------------------------
Resolution: Fixed
Closing as fixed as per Ajith. Please let us know if it is still a problem for you.
thanks,
dims
> 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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Chuck Williams (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376888 ]
Chuck Williams commented on AXIS2-608:
--------------------------------------
Hi Ajith,
FYI, the generated code does handle CDATA and unresolved ENTITIES because it uses getElementText() instead of getText(). getElementText() does all of the character consolidation. My app uses CDATA extensively because it passes html-valued parameters.
Your point about the state machines is good. I'll think they'll be great to have once they can be made fully robust.
Proper QName processing is important. I'll try your new template.
Thanks,
Chuck
> 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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Chuck Williams (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376387 ]
Chuck Williams commented on AXIS2-608:
--------------------------------------
I just saw the RC3 announcement and reminder about the 1.0 release plan. Will this bug be fixed for 1.0? It is still unassigned.
If the complete fix cannot get done in time, I'd argue that supporting minOccurs=0 and recursive data types is more important than enforcing order constraints when parsing sequences as the failures to handle the former are bugs while a failure to handle the latter is mostly just being lenient in the parser (except for the case of same-name different-property elements in a sequence, which limitation has an easy workaround). Applying the attached patch would yield that result.
Of course, it would be best to support all of these cases correctly, which requires a few code changes.
> 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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Chuck Williams (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376722 ]
Chuck Williams commented on AXIS2-608:
--------------------------------------
Hi Ajith,
Unfortunately the issue will need to remain open. I just tried my application and it failed with the latest axis2 from svn. This failure is for minOccurs=0, and I'm pretty sure other cases will fail too, including more complex cases of recursive data types that I didn't reach. I continue to hold by my position that the parsing can never be right if a loop invariant is not established for the reader position. Otherwise, you are forced to guess and cannot guess correctly in all cases. Here is the failing code from my applicaiton and the diagnosis as to why it is failing:
Here is the relevant wsdl:
<xsd:element name="stringListResponseElement" type="asxsd:StringListResponseType"/>
<xsd:complexType name="StringListResponseType">
<xsd:choice>
<xsd:element name="stringList" type="asxsd:StringList"/>
<xsd:element name="exception" type="asxsd:ExceptionType"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="StringList">
<xsd:sequence>
<xsd:element name="s" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
And here is the problematic parse() method generated by the lastest axis2:
public static StringList parse(javax.xml.stream.XMLStreamReader reader) throws java.lang.Exception{
StringList object = new StringList();
try {
int event = reader.getEventType();
//event better be a START_ELEMENT. if not we should go up to the start element here
while (event!= javax.xml.stream.XMLStreamReader.START_ELEMENT) {
event = reader.next();
}
org.apache.axis2.databinding.utils.SimpleArrayReaderStateMachine stateMachine1 = new
org.apache.axis2.databinding.utils.SimpleArrayReaderStateMachine();
stateMachine1.setElementNameToTest(new javax.xml.namespace.QName(
"",
"s"));
stateMachine1.setCanbeAbsent(true);
stateMachine1.read(reader);
java.lang.String[] textArray1 =
stateMachine1.getTextArray();
object.setS(
(java.lang.String[])
org.apache.axis2.databinding.utils.ConverterUtil.convertToArray(
java.lang.String.class,textArray1));
} catch (javax.xml.stream.XMLStreamException e) {
throw new java.lang.Exception(e);
}
return object;
}
When passed a valid <stringListResponseElement> with inner <stringList> that contains <s> elements as produced by the pull parser on the server side, here is the exception that is generated parsing this response on the client side:
java.lang.RuntimeException: java.lang.RuntimeException: Unexpected subelement s
at org.apache.axis2.AnalysisServiceStub.fromOM(AnalysisServiceStub.java:13495)
at org.apache.axis2.AnalysisServiceStub.listInvestigations(AnalysisServiceStub.java:1752)
at com.metalincs.analysiswebclient.actions.ListInvestigationsAction.execute(ListInvestigationsAction.java:55)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:419)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:224)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:362)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException: Unexpected subelement s
at org.apache.axis2.AnalysisServiceStub$StringListResponseType$Factory.parse(AnalysisServiceStub.java:4738)
at org.apache.axis2.AnalysisServiceStub$StringListResponseElement$Factory.parse(AnalysisServiceStub.java:4511)
at org.apache.axis2.AnalysisServiceStub.fromOM(AnalysisServiceStub.java:13459)
... 25 more
And here is the diagnosis:
I traced through the code. The problem is that the parse() method for StringList above has not advanced the reader when it starts parsing the properties. The reader is still pointed at the outer <stringList> when the state machine is called to parse the <s> elements. The <s> elements have minOccurs=0 and so can be omitted. The state machine sees the <stringList> element, which is not <s> and so it concludes there were no <s> elements. It returns and empty array rather than the correct array of the <s> element values. Then in the parse method for StringListResponseType it sees an <S> element which is not legal there and so it generates the exception. The failure is in not parsing the <stringList> properly.
The problem would be resolved by adding one line of code to position the reader for parsing the properties:
public static StringList parse(javax.xml.stream.XMLStreamReader reader) throws java.lang.Exception{
StringList object = new StringList();
try {
int event = reader.getEventType();
//event better be a START_ELEMENT. if not we should go up to the start element here
while (event!= javax.xml.stream.XMLStreamReader.START_ELEMENT) {
event = reader.next();
}
// ********* Advance reader to properties *********************
reader.next();
org.apache.axis2.databinding.utils.SimpleArrayReaderStateMachine stateMachine1 = new
org.apache.axis2.databinding.utils.SimpleArrayReaderStateMachine();
stateMachine1.setElementNameToTest(new javax.xml.namespace.QName(
"",
"s"));
stateMachine1.setCanbeAbsent(true);
stateMachine1.read(reader);
java.lang.String[] textArray1 =
stateMachine1.getTextArray();
object.setS(
(java.lang.String[])
org.apache.axis2.databinding.utils.ConverterUtil.convertToArray(
java.lang.String.class,textArray1));
} catch (javax.xml.stream.XMLStreamException e) {
throw new java.lang.Exception(e);
}
return object;
}
The <choice> template is careful about always positioning the reader correctly per my earlier description in this bug. Doing this makes everything much simpler. I continue to not see any way to parse without correct reader positioning.
It's 2:00 AM here and so I'm done for the day, but if this is still open tomorrow morning I will try to patch the template (and verify the state machines always position the reader consistently when they finish).
Chuck
> 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
[jira] Assigned: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Ajith Harshana Ranabahu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=all ]
Ajith Harshana Ranabahu reassigned AXIS2-608:
---------------------------------------------
Assign To: Ajith Harshana Ranabahu
> 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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Chuck Williams (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376867 ]
Chuck Williams commented on AXIS2-608:
--------------------------------------
Just one final note that codegen.patch is obsolete. It is replaced by codegen.src.patch and codegen.test.patch. This applies to Axis2 as of today's svn.
> 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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Ajith Harshana Ranabahu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376883 ]
Ajith Harshana Ranabahu commented on AXIS2-608:
-----------------------------------------------
Hi Chuck,
I've done almost the same changes to the template but your template seemed to have some good code which I wanted to incorporate. What is primarily different in my code is the use of Qname instead of localname. Hence I've merged the two templates and also modified the test cases
As for the state machines my look at the codegen is that all the parsing tasks are almost similar except the QNames you look for is different. So what I believe is that by having a set of generic state machines we can delegate the work to the state machines which makes the generated code much simpler. As for the events such as CDATA I'm not sure whether the generated code would handle it properly either :)
I've checked in another test and the modified classes/templates
> 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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Chuck Williams (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376861 ]
Chuck Williams commented on AXIS2-608:
--------------------------------------
FYI, I expect to have a patch with a complete solution very soon. All Axis2 tests pass (after patching the MinOccurs tests as before to accept null property values for arays when minOccurs=0 and the no element property is present) and most of my application runs. One complex recursive data type case failed -- I'm rebuilding and retesting a fix for that now.
This patch handles minOccurs=0, recursive data types, choice and enforces the order of properties in sequences.
I tried to do this with the new state machine code, but ran into too many problems, I think these would need considerably more work before they would be in a releasable state. E.g., I don't see how they handle consolidation of CHARARACTER events, CDATA sections, or unresolved ENTITY references, and I found issues in some of the state transitions.
So, to resolve all parts of this issue, I used the approach outlined above, i.e. the "choice" template (which is the patched 0.94 code) is used for all cases, and has been extended to enforce the oder of properties for sequence types.
Patch coming very soon.
> 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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Chuck Williams (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376395 ]
Chuck Williams commented on AXIS2-608:
--------------------------------------
Hi Ajith,
Thanks! A fix that uses the state machines is fine with me. I only patched the older 0.94 template rather than the newer state machine 0.95 template because I already had the 0.94 patch and was more familiar with that code at the time.
In addition to minOccurs=0, recursive data types are also important, i.e. an element with a subelement of the same name (and possibly the same type or possibly a different type). I believe that fixing that requires that the parse() method advance the reader past its own start element prior to parsing its properties, else there is no way to distinguish the parse element itself from a first property with the same name. This is how the patched parser starts. The other key is to ensure that the parse of each property advances past its end element, so that it is certain that the next start or end element starts a new property or ends the outer original element being parsed.
I'd be happy to test a fix prior to the 1.0 release, either by loading some new files on top of RC2 or by building from svn. Please let me know if I can help test it.
Thanks,
Chuck
> 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
[jira] Resolved: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Ajith Harshana Ranabahu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=all ]
Ajith Harshana Ranabahu resolved AXIS2-608:
-------------------------------------------
Resolution: Fixed
This seems reasonbaly solved hence I'm marking this as done
> 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
[jira] Updated: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Chuck Williams (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=all ]
Chuck Williams updated AXIS2-608:
---------------------------------
Attachment: codegen.src.patch
codegen.src.patch corrects all issues as described above in ADBBeanTemplate. This is a gnu standard patch (diff -u) that applies to codegen/src. The next patch file addresses issues in two test cases that required for axis2 with this patch applied to pass all tests.
As there have been problems with svn applying gnu standard patches, I'll also attach the modified source files.
> 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, 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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Ajith Harshana Ranabahu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376482 ]
Ajith Harshana Ranabahu commented on AXIS2-608:
-----------------------------------------------
I've checked in a fix for the minoccurs=0 case . Please run a test and let me know
> 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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Sanjiva Weerawarana (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376727 ]
Sanjiva Weerawarana commented on AXIS2-608:
-------------------------------------------
I agree this issue is not fixable with a few hacks. I wonder whether we should back down to the model of saying we don't support <sequence> fully yet (i.e., don't enforce the order constraint; treat it as <all>) and use the version that Chuck came up with earlier which does support fully recursive types? From an 80-20 split p.o.v. I would argue that supporting that fully is more important than doing the order constraint.
Ajith, what do you think? I'm trying to find a way to get past this with an 80-20 answer ... it seems to me that getting this fully sorted out will take a long time.
> 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
[jira] Updated: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Chuck Williams (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=all ]
Chuck Williams updated AXIS2-608:
---------------------------------
Attachment: codegen.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
> 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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Chuck Williams (JIRA)" <ji...@apache.org>.
[ 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
Re: [jira] Commented: (AXIS2-608) Generated ADB code fails on omitted scalar minOccurs=0 elements and recursive data types
Posted by Davanum Srinivas <da...@gmail.com>.
Please try "maven -o -Dmaven.test.skip=true" (offline build and skip the tests)
thanks,
dims
On 4/26/06, Chuck Williams <ch...@manawiz.com> wrote:
> Are there any plans to reduce or eliminate the SNAPSHOT dependencies? My
> build is still running almost an hour later, and now I'm getting stuff like
> this:
>
> Error retrieving artifact from
> [http://www.apache.org/dist/java-repository/axis2/jars/axis2-core-SNAPSHOT.jar]:
> java.net.ConnectException: Connection timed out
>
> This is just doing "maven".
>
> Chuck
>
>
> Chuck Williams wrote on 04/26/2006 03:55 PM:
> Thanks Sanjiva. Working on it now and will attach the patch for recursive
> data types.
>
> Chuck
>
>
> Sanjiva Weerawarana wrote on 04/26/2006 02:36 PM:
> On Wed, 2006-04-26 at 21:26 +0000, Chuck Williams (JIRA) wrote:
>
>
> [
> http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376557
> ]
>
> Chuck Williams commented on AXIS2-608:
> --------------------------------------
>
> Ajith,
>
> Are these the only files required for your udpate?
>
> U
> modules/adb/src/org/apache/axis2/databinding/utils/SimpleArrayReaderStateMachine.java
> U
> modules/adb/src/org/apache/axis2/databinding/utils/SimpleElementReaderStateMachine.java
> U
> modules/codegen/src/org/apache/axis2/schema/template/ADBBeanTemplate.xsl
>
>
> If you can give me a list of files for a stable upgrade, or if you are
> reasonably confident an svn update will yield a stable configuration,
> then I'll do the upgrade and patch the new template.
>
> The build is spsed to be stable these days .. if not we have big(ger)
> problems!
>
> I'd go ahead and take an svn update and try.
>
> Thanks for your persistence in getting this fixed right and for your
> patches!
>
> Sanjiva.
>
>
>
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: [jira] Commented: (AXIS2-608) Generated ADB code fails on
omitted scalar minOccurs=0 elements and recursive data types
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Wed, 2006-04-26 at 21:26 +0000, Chuck Williams (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376557 ]
>
> Chuck Williams commented on AXIS2-608:
> --------------------------------------
>
> Ajith,
>
> Are these the only files required for your udpate?
>
> U modules/adb/src/org/apache/axis2/databinding/utils/SimpleArrayReaderStateMachine.java
> U modules/adb/src/org/apache/axis2/databinding/utils/SimpleElementReaderStateMachine.java
> U modules/codegen/src/org/apache/axis2/schema/template/ADBBeanTemplate.xsl
>
>
> If you can give me a list of files for a stable upgrade, or if you are
> reasonably confident an svn update will yield a stable configuration,
> then I'll do the upgrade and patch the new template.
The build is spsed to be stable these days .. if not we have big(ger)
problems!
I'd go ahead and take an svn update and try.
Thanks for your persistence in getting this fixed right and for your
patches!
Sanjiva.
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Chuck Williams (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376557 ]
Chuck Williams commented on AXIS2-608:
--------------------------------------
Ajith,
Are these the only files required for your udpate?
U modules/adb/src/org/apache/axis2/databinding/utils/SimpleArrayReaderStateMachine.java
U modules/adb/src/org/apache/axis2/databinding/utils/SimpleElementReaderStateMachine.java
U modules/codegen/src/org/apache/axis2/schema/template/ADBBeanTemplate.xsl
If you can give me a list of files for a stable upgrade, or if you are reasonably confident an svn update will yield a stable configuration, then I'll do the upgrade and patch the new template.
Thanks,
Chuck
> 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
[jira] Updated: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Chuck Williams (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=all ]
Chuck Williams updated AXIS2-608:
---------------------------------
Attachment: PopulateMinOccurs0Test.java
First of the two changed MinOccurs tests.
> 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, 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
[jira] Updated: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Chuck Williams (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (AXIS2-608) Generated ADB code fails on omitted
scalar minOccurs=0 elements and recursive data types
Posted by "Chuck Williams (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-608?page=comments#action_12376550 ]
Chuck Williams commented on AXIS2-608:
--------------------------------------
Please reopen this issue. Ajith only addressed the minOccurs=0 case, not recursive data types.
I did not run the test as it is fairly hard for me to upgrade to a new version of Axis2, but the issue is apparent by looking at the code. E.g., consider an element like this:
<E>
<E>
foo
</E>
<E>
The parse() method for the outer <E> leaves the reader positioned at its own start element when it begins to look for its properties. It then finds itself rather than the inner <E> as the inner property!
As I wrote earlier, parsing can only be done correctly if there is a loop invariant for the reader position. The reader needs to be at the event after the outer element start before the property scanning begins, and then each property needs to leave the reader at the event after its end element.
The template for the <choice> case works this way. This invariant makes both minOccurs=0 and recursive data types straightforward.
> 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