Re: binary and enumFacet are incompatible with unordered in ADBBeanTemplate
As of this morning, build is not broken. Please get a fresh nightly and try again. there was a backward compat flag problem which i fixed yesterday. -- dims On 9/6/06, Chuck Williams <[EMAIL PROTECTED]> wrote: Hi Dims and Ajith, I believe you guys added revisions 434331 and 436663 as part of a fix for Axis2-1065. Unfortunately these changes break the build and the template. E.g., the sforce enterprise wsdl generates bogus code and kills a clean build. Simply backing out the changes in these two revisions causes the build to succeed and all tests to pass. However, I suspect this will regress Axis2-1065 and the same type of problem exists for enumFacet. The issue is this. For ordered property sets, the main property parsing loop generates code like this (in pseudo-code notation): if (elementName=="name1") { ... } else throw "Unexpected subelement" if (elementName=="name2") { ... } else throw "Unexpected subelement" ... While in the unordered case the same code looks like this: while (!endElement) { if (elementName=="name1") { ... } else if (elementName=="name2") { ... } ... } The binary MTOM code that was added fills the role of one the embedded if's but is not of the same form, not an if at all. This code works in the first ordered case, but in the second unordered case it doesn't work at all to have fixed code expecting to just read a binary value where one of the if's is supposed to be. Also in the binary case in the current template the else is still generated after the MTOM code that is not an if, whence the syntax violation in the code generated for the sforce wsdl, which evidently has a binary property in an unordered property set. I'm no expert on MTOM. Can't you still test that you've got the right property (the binary property) by using the start-element name? For the template to work in the unordered case, some test that you've got the binary propery is essential. The existing template does not do this, which can only work in the ordered case where you know you are at the right position, and even in this case does not do the proper error checking to verify this. I would commit the attached template as axis2 passes all tests, but the logs indicate you made the revisions that created this problem to fix another problem and so I don't want to just back that out without bringing this to your attention first. Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Axis2] Fwd: binary and enumFacet are incompatible with unordered in ADBBeanTemplate
Forwarding with the Axis2 prefix. I nearly missed it :) BTW I guess these changes are done by Dims and Thilina for MTOM compatibility so I guess they are the best people to test what went wrong here :) On 9/6/06, Chuck Williams <[EMAIL PROTECTED]> wrote: Hi Dims and Ajith, I believe you guys added revisions 434331 and 436663 as part of a fix for Axis2-1065. Unfortunately these changes break the build and the template. E.g., the sforce enterprise wsdl generates bogus code and kills a clean build. Simply backing out the changes in these two revisions causes the build to succeed and all tests to pass. However, I suspect this will regress Axis2-1065 and the same type of problem exists for enumFacet. The issue is this. For ordered property sets, the main property parsing loop generates code like this (in pseudo-code notation): if (elementName=="name1") { ... } else throw "Unexpected subelement" if (elementName=="name2") { ... } else throw "Unexpected subelement" ... While in the unordered case the same code looks like this: while (!endElement) { if (elementName=="name1") { ... } else if (elementName=="name2") { ... } ... } The binary MTOM code that was added fills the role of one the embedded if's but is not of the same form, not an if at all. This code works in the first ordered case, but in the second unordered case it doesn't work at all to have fixed code expecting to just read a binary value where one of the if's is supposed to be. Also in the binary case in the current template the else is still generated after the MTOM code that is not an if, whence the syntax violation in the code generated for the sforce wsdl, which evidently has a binary property in an unordered property set. I'm no expert on MTOM. Can't you still test that you've got the right property (the binary property) by using the start-element name? For the template to work in the unordered case, some test that you've got the binary propery is essential. The existing template does not do this, which can only work in the ordered case where you know you are at the right position, and even in this case does not do the proper error checking to verify this. I would commit the attached template as axis2 passes all tests, but the logs indicate you made the revisions that created this problem to fix another problem and so I don't want to just back that out without bringing this to your attention first. Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ajith Ranabahu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] binary and enumFacet are incompatible with unordered in ADBBeanTemplate
Thanks Dims. I'm trying a build now. It takes a long time from here due to all the maven library access delays (I already tried offline, which failed hopefully only because a new library is requried). The problems I've noted with the template remain. In the unordered case the code inserts binary (or enumFacet) code into a looping structure that looks for each property in any order. Each iteration of the loop must check to see what property it is at and then load that value using whatever method is correct. The code structure of the loop presumes that each such property-loading code segment is an single if statement that can be preceded by an "else" as there is no need to continue checking properties in a single iteration once one is found. However, the code generated for binary and enumFacet properties satisfies neither of these criteria. This code does not check to see if it is at the property it loads and it is not in the form of an if. This causes invalid code to be generated. The binary and and enumFacet generated code will only work in an ordered context. With a binary MTOM property is it still possible to validate the property by checking the name of the start element? If so, my fix (which just backs out 434331 and 436663) will work. If not, then some other test needs to be devised if binary attributes are to work in an unordered context. I'd be happy to fix if you could answer that question. Thanks, Chuck Davanum Srinivas wrote on 09/07/2006 12:17 AM: > As of this morning, build is not broken. Please get a fresh nightly > and try again. there was a backward compat flag problem which i fixed > yesterday. > > -- dims > > On 9/6/06, Chuck Williams <[EMAIL PROTECTED]> wrote: >> Hi Dims and Ajith, >> >> I believe you guys added revisions 434331 and 436663 as part of a fix >> for Axis2-1065. Unfortunately these changes break the build and the >> template. E.g., the sforce enterprise wsdl generates bogus code and >> kills a clean build. >> >> Simply backing out the changes in these two revisions causes the build >> to succeed and all tests to pass. However, I suspect this will regress >> Axis2-1065 and the same type of problem exists for enumFacet. >> >> The issue is this. For ordered property sets, the main property parsing >> loop generates code like this (in pseudo-code notation): >> >> if (elementName=="name1") { >> ... >> } else throw "Unexpected subelement" >> >> if (elementName=="name2") { >> ... >> } else throw "Unexpected subelement" >> >> ... >> >> While in the unordered case the same code looks like this: >> >> while (!endElement) { >> if (elementName=="name1") { >> ... >> } >> else if (elementName=="name2") { >> ... >> } >> ... >> } >> >> The binary MTOM code that was added fills the role of one the embedded >> if's but is not of the same form, not an if at all. This code works in >> the first ordered case, but in the second unordered case it doesn't work >> at all to have fixed code expecting to just read a binary value where >> one of the if's is supposed to be. Also in the binary case in the >> current template the else is still generated after the MTOM code that is >> not an if, whence the syntax violation in the code generated for the >> sforce wsdl, which evidently has a binary property in an unordered >> property set. >> >> I'm no expert on MTOM. Can't you still test that you've got the right >> property (the binary property) by using the start-element name? For the >> template to work in the unordered case, some test that you've got the >> binary propery is essential. The existing template does not do this, >> which can only work in the ordered case where you know you are at the >> right position, and even in this case does not do the proper error >> checking to verify this. >> >> I would commit the attached template as axis2 passes all tests, but the >> logs indicate you made the revisions that created this problem to fix >> another problem and so I don't want to just back that out without >> bringing this to your attention first. >> >> Chuck >> >> >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] binary and enumFacet are incompatible with unordered in ADBBeanTemplate
I've added a JIRA issue: http://issues.apache.org/jira/browse/AXIS2-1121 thanks, -- dims On 9/7/06, Chuck Williams <[EMAIL PROTECTED]> wrote: Thanks Dims. I'm trying a build now. It takes a long time from here due to all the maven library access delays (I already tried offline, which failed hopefully only because a new library is requried). The problems I've noted with the template remain. In the unordered case the code inserts binary (or enumFacet) code into a looping structure that looks for each property in any order. Each iteration of the loop must check to see what property it is at and then load that value using whatever method is correct. The code structure of the loop presumes that each such property-loading code segment is an single if statement that can be preceded by an "else" as there is no need to continue checking properties in a single iteration once one is found. However, the code generated for binary and enumFacet properties satisfies neither of these criteria. This code does not check to see if it is at the property it loads and it is not in the form of an if. This causes invalid code to be generated. The binary and and enumFacet generated code will only work in an ordered context. With a binary MTOM property is it still possible to validate the property by checking the name of the start element? If so, my fix (which just backs out 434331 and 436663) will work. If not, then some other test needs to be devised if binary attributes are to work in an unordered context. I'd be happy to fix if you could answer that question. Thanks, Chuck Davanum Srinivas wrote on 09/07/2006 12:17 AM: > As of this morning, build is not broken. Please get a fresh nightly > and try again. there was a backward compat flag problem which i fixed > yesterday. > > -- dims > > On 9/6/06, Chuck Williams <[EMAIL PROTECTED]> wrote: >> Hi Dims and Ajith, >> >> I believe you guys added revisions 434331 and 436663 as part of a fix >> for Axis2-1065. Unfortunately these changes break the build and the >> template. E.g., the sforce enterprise wsdl generates bogus code and >> kills a clean build. >> >> Simply backing out the changes in these two revisions causes the build >> to succeed and all tests to pass. However, I suspect this will regress >> Axis2-1065 and the same type of problem exists for enumFacet. >> >> The issue is this. For ordered property sets, the main property parsing >> loop generates code like this (in pseudo-code notation): >> >> if (elementName=="name1") { >> ... >> } else throw "Unexpected subelement" >> >> if (elementName=="name2") { >> ... >> } else throw "Unexpected subelement" >> >> ... >> >> While in the unordered case the same code looks like this: >> >> while (!endElement) { >> if (elementName=="name1") { >> ... >> } >> else if (elementName=="name2") { >> ... >> } >> ... >> } >> >> The binary MTOM code that was added fills the role of one the embedded >> if's but is not of the same form, not an if at all. This code works in >> the first ordered case, but in the second unordered case it doesn't work >> at all to have fixed code expecting to just read a binary value where >> one of the if's is supposed to be. Also in the binary case in the >> current template the else is still generated after the MTOM code that is >> not an if, whence the syntax violation in the code generated for the >> sforce wsdl, which evidently has a binary property in an unordered >> property set. >> >> I'm no expert on MTOM. Can't you still test that you've got the right >> property (the binary property) by using the start-element name? For the >> template to work in the unordered case, some test that you've got the >> binary propery is essential. The existing template does not do this, >> which can only work in the ordered case where you know you are at the >> right position, and even in this case does not do the proper error >> checking to verify this. >> >> I would commit the attached template as axis2 passes all tests, but the >> logs indicate you made the revisions that created this problem to fix >> another problem and so I don't want to just back that out without >> bringing this to your attention first. >> >> Chuck >> >> >> >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] binary and enumFacet are incompatible with unordered in ADBBeanTemplate
And checked in a fix as well. -- dims On 9/7/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote: I've added a JIRA issue: http://issues.apache.org/jira/browse/AXIS2-1121 thanks, -- dims On 9/7/06, Chuck Williams <[EMAIL PROTECTED]> wrote: > Thanks Dims. I'm trying a build now. It takes a long time from here > due to all the maven library access delays (I already tried offline, > which failed hopefully only because a new library is requried). > > The problems I've noted with the template remain. In the unordered case > the code inserts binary (or enumFacet) code into a looping structure > that looks for each property in any order. Each iteration of the loop > must check to see what property it is at and then load that value using > whatever method is correct. The code structure of the loop presumes > that each such property-loading code segment is an single if statement > that can be preceded by an "else" as there is no need to continue > checking properties in a single iteration once one is found. However, > the code generated for binary and enumFacet properties satisfies neither > of these criteria. This code does not check to see if it is at the > property it loads and it is not in the form of an if. This causes > invalid code to be generated. The binary and and enumFacet generated > code will only work in an ordered context. > > With a binary MTOM property is it still possible to validate the > property by checking the name of the start element? If so, my fix > (which just backs out 434331 and 436663) will work. If not, then some > other test needs to be devised if binary attributes are to work in an > unordered context. > > I'd be happy to fix if you could answer that question. > > Thanks, > > Chuck > > > Davanum Srinivas wrote on 09/07/2006 12:17 AM: > > As of this morning, build is not broken. Please get a fresh nightly > > and try again. there was a backward compat flag problem which i fixed > > yesterday. > > > > -- dims > > > > On 9/6/06, Chuck Williams <[EMAIL PROTECTED]> wrote: > >> Hi Dims and Ajith, > >> > >> I believe you guys added revisions 434331 and 436663 as part of a fix > >> for Axis2-1065. Unfortunately these changes break the build and the > >> template. E.g., the sforce enterprise wsdl generates bogus code and > >> kills a clean build. > >> > >> Simply backing out the changes in these two revisions causes the build > >> to succeed and all tests to pass. However, I suspect this will regress > >> Axis2-1065 and the same type of problem exists for enumFacet. > >> > >> The issue is this. For ordered property sets, the main property parsing > >> loop generates code like this (in pseudo-code notation): > >> > >> if (elementName=="name1") { > >> ... > >> } else throw "Unexpected subelement" > >> > >> if (elementName=="name2") { > >> ... > >> } else throw "Unexpected subelement" > >> > >> ... > >> > >> While in the unordered case the same code looks like this: > >> > >> while (!endElement) { > >> if (elementName=="name1") { > >> ... > >> } > >> else if (elementName=="name2") { > >> ... > >> } > >> ... > >> } > >> > >> The binary MTOM code that was added fills the role of one the embedded > >> if's but is not of the same form, not an if at all. This code works in > >> the first ordered case, but in the second unordered case it doesn't work > >> at all to have fixed code expecting to just read a binary value where > >> one of the if's is supposed to be. Also in the binary case in the > >> current template the else is still generated after the MTOM code that is > >> not an if, whence the syntax violation in the code generated for the > >> sforce wsdl, which evidently has a binary property in an unordered > >> property set. > >> > >> I'm no expert on MTOM. Can't you still test that you've got the right > >> property (the binary property) by using the start-element name? For the > >> template to work in the unordered case, some test that you've got the > >> binary propery is essential. The existing template does not do this, > >> which can only work in the ordered case where you know you are at the > >> right position, and even in this case does not do the proper error > >> checking to verify this. > >> > >> I would commit the attached template as axis2 passes all tests, but the > >> logs indicate you made the revisions that created this problem to fix > >> another problem and so I don't want to just back that out without > >> bringing this to your attention first. > >> > >> Chuck > >> > >> > >> > >> > >> > >> - > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas : http://www.wso2.net (Oxygen fo
[jira] Created: (AXIS2-1121) binary and enumFacet are incompatible with unordered in ADBBeanTemplate
binary and enumFacet are incompatible with unordered in ADBBeanTemplate --- Key: AXIS2-1121 URL: http://issues.apache.org/jira/browse/AXIS2-1121 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Reporter: Davanum Srinivas Hi Dims and Ajith, I believe you guys added revisions 434331 and 436663 as part of a fix for Axis2-1065. Unfortunately these changes break the build and the template. E.g., the sforce enterprise wsdl generates bogus code and kills a clean build. Simply backing out the changes in these two revisions causes the build to succeed and all tests to pass. However, I suspect this will regress Axis2-1065 and the same type of problem exists for enumFacet. The issue is this. For ordered property sets, the main property parsing loop generates code like this (in pseudo-code notation): if (elementName=="name1") { ... } else throw "Unexpected subelement" if (elementName=="name2") { ... } else throw "Unexpected subelement" ... While in the unordered case the same code looks like this: while (!endElement) { if (elementName=="name1") { ... } else if (elementName=="name2") { ... } ... } The binary MTOM code that was added fills the role of one the embedded if's but is not of the same form, not an if at all. This code works in the first ordered case, but in the second unordered case it doesn't work at all to have fixed code expecting to just read a binary value where one of the if's is supposed to be. Also in the binary case in the current template the else is still generated after the MTOM code that is not an if, whence the syntax violation in the code generated for the sforce wsdl, which evidently has a binary property in an unordered property set. I'm no expert on MTOM. Can't you still test that you've got the right property (the binary property) by using the start-element name? For the template to work in the unordered case, some test that you've got the binary propery is essential. The existing template does not do this, which can only work in the ordered case where you know you are at the right position, and even in this case does not do the proper error checking to verify this. I would commit the attached template as axis2 passes all tests, but the logs indicate you made the revisions that created this problem to fix another problem and so I don't want to just back that out without bringing this to your attention first. Chuck -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1121) binary and enumFacet are incompatible with unordered in ADBBeanTemplate
[ http://issues.apache.org/jira/browse/AXIS2-1121?page=comments#action_12433224 ] Davanum Srinivas commented on AXIS2-1121: - Thanks Dims. I'm trying a build now. It takes a long time from here due to all the maven library access delays (I already tried offline, which failed hopefully only because a new library is requried). The problems I've noted with the template remain. In the unordered case the code inserts binary (or enumFacet) code into a looping structure that looks for each property in any order. Each iteration of the loop must check to see what property it is at and then load that value using whatever method is correct. The code structure of the loop presumes that each such property-loading code segment is an single if statement that can be preceded by an "else" as there is no need to continue checking properties in a single iteration once one is found. However, the code generated for binary and enumFacet properties satisfies neither of these criteria. This code does not check to see if it is at the property it loads and it is not in the form of an if. This causes invalid code to be generated. The binary and and enumFacet generated code will only work in an ordered context. With a binary MTOM property is it still possible to validate the property by checking the name of the start element? If so, my fix (which just backs out 434331 and 436663) will work. If not, then some other test needs to be devised if binary attributes are to work in an unordered context. I'd be happy to fix if you could answer that question. Thanks, Chuck > binary and enumFacet are incompatible with unordered in ADBBeanTemplate > --- > > Key: AXIS2-1121 > URL: http://issues.apache.org/jira/browse/AXIS2-1121 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug >Reporter: Davanum Srinivas > > Hi Dims and Ajith, > I believe you guys added revisions 434331 and 436663 as part of a fix > for Axis2-1065. Unfortunately these changes break the build and the > template. E.g., the sforce enterprise wsdl generates bogus code and > kills a clean build. > Simply backing out the changes in these two revisions causes the build > to succeed and all tests to pass. However, I suspect this will regress > Axis2-1065 and the same type of problem exists for enumFacet. > The issue is this. For ordered property sets, the main property parsing > loop generates code like this (in pseudo-code notation): > if (elementName=="name1") { >... > } else throw "Unexpected subelement" > if (elementName=="name2") { >... > } else throw "Unexpected subelement" > ... > While in the unordered case the same code looks like this: > while (!endElement) { >if (elementName=="name1") { >... >} >else if (elementName=="name2") { >... >} >... > } > The binary MTOM code that was added fills the role of one the embedded > if's but is not of the same form, not an if at all. This code works in > the first ordered case, but in the second unordered case it doesn't work > at all to have fixed code expecting to just read a binary value where > one of the if's is supposed to be. Also in the binary case in the > current template the else is still generated after the MTOM code that is > not an if, whence the syntax violation in the code generated for the > sforce wsdl, which evidently has a binary property in an unordered > property set. > I'm no expert on MTOM. Can't you still test that you've got the right > property (the binary property) by using the start-element name? For the > template to work in the unordered case, some test that you've got the > binary propery is essential. The existing template does not do this, > which can only work in the ordered case where you know you are at the > right position, and even in this case does not do the proper error > checking to verify this. > I would commit the attached template as axis2 passes all tests, but the > logs indicate you made the revisions that created this problem to fix > another problem and so I don't want to just back that out without > bringing this to your attention first. > Chuck -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-1121) binary and enumFacet are incompatible with unordered in ADBBeanTemplate
[ http://issues.apache.org/jira/browse/AXIS2-1121?page=all ] Davanum Srinivas resolved AXIS2-1121. - Resolution: Fixed Fixed. Please see http://svn.apache.org/viewvc?view=rev&revision=441219. Basically i reverted the 2 checkins 436663 and 434331 and in the case of binary won't check the propQName. Will this work for you? thanks, dims > binary and enumFacet are incompatible with unordered in ADBBeanTemplate > --- > > Key: AXIS2-1121 > URL: http://issues.apache.org/jira/browse/AXIS2-1121 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug >Reporter: Davanum Srinivas > > Hi Dims and Ajith, > I believe you guys added revisions 434331 and 436663 as part of a fix > for Axis2-1065. Unfortunately these changes break the build and the > template. E.g., the sforce enterprise wsdl generates bogus code and > kills a clean build. > Simply backing out the changes in these two revisions causes the build > to succeed and all tests to pass. However, I suspect this will regress > Axis2-1065 and the same type of problem exists for enumFacet. > The issue is this. For ordered property sets, the main property parsing > loop generates code like this (in pseudo-code notation): > if (elementName=="name1") { >... > } else throw "Unexpected subelement" > if (elementName=="name2") { >... > } else throw "Unexpected subelement" > ... > While in the unordered case the same code looks like this: > while (!endElement) { >if (elementName=="name1") { >... >} >else if (elementName=="name2") { >... >} >... > } > The binary MTOM code that was added fills the role of one the embedded > if's but is not of the same form, not an if at all. This code works in > the first ordered case, but in the second unordered case it doesn't work > at all to have fixed code expecting to just read a binary value where > one of the if's is supposed to be. Also in the binary case in the > current template the else is still generated after the MTOM code that is > not an if, whence the syntax violation in the code generated for the > sforce wsdl, which evidently has a binary property in an unordered > property set. > I'm no expert on MTOM. Can't you still test that you've got the right > property (the binary property) by using the start-element name? For the > template to work in the unordered case, some test that you've got the > binary propery is essential. The existing template does not do this, > which can only work in the ordered case where you know you are at the > right position, and even in this case does not do the proper error > checking to verify this. > I would commit the attached template as axis2 passes all tests, but the > logs indicate you made the revisions that created this problem to fix > another problem and so I don't want to just back that out without > bringing this to your attention first. > Chuck -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1121) binary and enumFacet are incompatible with unordered in ADBBeanTemplate
[ http://issues.apache.org/jira/browse/AXIS2-1121?page=comments#action_12433257 ] Chuck Williams commented on AXIS2-1121: --- Dims, Thanks for making this update. I still have not managed to get a successful build (last attempt failed tests in the security scenarios due to check-ins today), but have reviewed the changes to the template. I see that you explicitly did not check for being at the right property in the unordered case (omitted the test of the start element name) and so presume that for some reason this is not possible. This means the binary property code will be evaluated on every iteration of the loop for any container with at least one binary property. I don't see how this could work. In the sforce wsdl that failed yesterday, it has an unordered type with both binary and non-binary properties. The unordered property parsing loop can only work if it can detect when it has reached the binary property. If the start element name cannot be used for this, is there some other test that can? I wrote the portions of the template that pertain to the unordered case and understand it well, but I don't understand MTOM fully. I've read the spec and don't see why testing the start element name cannot be done. If you could explain how to test that the binary property has been reached I could fix the the template. > binary and enumFacet are incompatible with unordered in ADBBeanTemplate > --- > > Key: AXIS2-1121 > URL: http://issues.apache.org/jira/browse/AXIS2-1121 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug >Reporter: Davanum Srinivas > > Hi Dims and Ajith, > I believe you guys added revisions 434331 and 436663 as part of a fix > for Axis2-1065. Unfortunately these changes break the build and the > template. E.g., the sforce enterprise wsdl generates bogus code and > kills a clean build. > Simply backing out the changes in these two revisions causes the build > to succeed and all tests to pass. However, I suspect this will regress > Axis2-1065 and the same type of problem exists for enumFacet. > The issue is this. For ordered property sets, the main property parsing > loop generates code like this (in pseudo-code notation): > if (elementName=="name1") { >... > } else throw "Unexpected subelement" > if (elementName=="name2") { >... > } else throw "Unexpected subelement" > ... > While in the unordered case the same code looks like this: > while (!endElement) { >if (elementName=="name1") { >... >} >else if (elementName=="name2") { >... >} >... > } > The binary MTOM code that was added fills the role of one the embedded > if's but is not of the same form, not an if at all. This code works in > the first ordered case, but in the second unordered case it doesn't work > at all to have fixed code expecting to just read a binary value where > one of the if's is supposed to be. Also in the binary case in the > current template the else is still generated after the MTOM code that is > not an if, whence the syntax violation in the code generated for the > sforce wsdl, which evidently has a binary property in an unordered > property set. > I'm no expert on MTOM. Can't you still test that you've got the right > property (the binary property) by using the start-element name? For the > template to work in the unordered case, some test that you've got the > binary propery is essential. The existing template does not do this, > which can only work in the ordered case where you know you are at the > right position, and even in this case does not do the proper error > checking to verify this. > I would commit the attached template as axis2 passes all tests, but the > logs indicate you made the revisions that created this problem to fix > another problem and so I don't want to just back that out without > bringing this to your attention first. > Chuck -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (AXIS2-1121) binary and enumFacet are incompatible with unordered in ADBBeanTemplate
[ http://issues.apache.org/jira/browse/AXIS2-1121?page=all ] Davanum Srinivas reopened AXIS2-1121: - > binary and enumFacet are incompatible with unordered in ADBBeanTemplate > --- > > Key: AXIS2-1121 > URL: http://issues.apache.org/jira/browse/AXIS2-1121 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug >Reporter: Davanum Srinivas > > Hi Dims and Ajith, > I believe you guys added revisions 434331 and 436663 as part of a fix > for Axis2-1065. Unfortunately these changes break the build and the > template. E.g., the sforce enterprise wsdl generates bogus code and > kills a clean build. > Simply backing out the changes in these two revisions causes the build > to succeed and all tests to pass. However, I suspect this will regress > Axis2-1065 and the same type of problem exists for enumFacet. > The issue is this. For ordered property sets, the main property parsing > loop generates code like this (in pseudo-code notation): > if (elementName=="name1") { >... > } else throw "Unexpected subelement" > if (elementName=="name2") { >... > } else throw "Unexpected subelement" > ... > While in the unordered case the same code looks like this: > while (!endElement) { >if (elementName=="name1") { >... >} >else if (elementName=="name2") { >... >} >... > } > The binary MTOM code that was added fills the role of one the embedded > if's but is not of the same form, not an if at all. This code works in > the first ordered case, but in the second unordered case it doesn't work > at all to have fixed code expecting to just read a binary value where > one of the if's is supposed to be. Also in the binary case in the > current template the else is still generated after the MTOM code that is > not an if, whence the syntax violation in the code generated for the > sforce wsdl, which evidently has a binary property in an unordered > property set. > I'm no expert on MTOM. Can't you still test that you've got the right > property (the binary property) by using the start-element name? For the > template to work in the unordered case, some test that you've got the > binary propery is essential. The existing template does not do this, > which can only work in the ordered case where you know you are at the > right position, and even in this case does not do the proper error > checking to verify this. > I would commit the attached template as axis2 passes all tests, but the > logs indicate you made the revisions that created this problem to fix > another problem and so I don't want to just back that out without > bringing this to your attention first. > Chuck -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-1121) binary and enumFacet are incompatible with unordered in ADBBeanTemplate
[ http://issues.apache.org/jira/browse/AXIS2-1121?page=all ] Davanum Srinivas resolved AXIS2-1121. - Resolution: Fixed Fix in r442593 -- dims > binary and enumFacet are incompatible with unordered in ADBBeanTemplate > --- > > Key: AXIS2-1121 > URL: http://issues.apache.org/jira/browse/AXIS2-1121 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug >Reporter: Davanum Srinivas > > Hi Dims and Ajith, > I believe you guys added revisions 434331 and 436663 as part of a fix > for Axis2-1065. Unfortunately these changes break the build and the > template. E.g., the sforce enterprise wsdl generates bogus code and > kills a clean build. > Simply backing out the changes in these two revisions causes the build > to succeed and all tests to pass. However, I suspect this will regress > Axis2-1065 and the same type of problem exists for enumFacet. > The issue is this. For ordered property sets, the main property parsing > loop generates code like this (in pseudo-code notation): > if (elementName=="name1") { >... > } else throw "Unexpected subelement" > if (elementName=="name2") { >... > } else throw "Unexpected subelement" > ... > While in the unordered case the same code looks like this: > while (!endElement) { >if (elementName=="name1") { >... >} >else if (elementName=="name2") { >... >} >... > } > The binary MTOM code that was added fills the role of one the embedded > if's but is not of the same form, not an if at all. This code works in > the first ordered case, but in the second unordered case it doesn't work > at all to have fixed code expecting to just read a binary value where > one of the if's is supposed to be. Also in the binary case in the > current template the else is still generated after the MTOM code that is > not an if, whence the syntax violation in the code generated for the > sforce wsdl, which evidently has a binary property in an unordered > property set. > I'm no expert on MTOM. Can't you still test that you've got the right > property (the binary property) by using the start-element name? For the > template to work in the unordered case, some test that you've got the > binary propery is essential. The existing template does not do this, > which can only work in the ordered case where you know you are at the > right position, and even in this case does not do the proper error > checking to verify this. > I would commit the attached template as axis2 passes all tests, but the > logs indicate you made the revisions that created this problem to fix > another problem and so I don't want to just back that out without > bringing this to your attention first. > Chuck -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]