[ http://issues.apache.org/jira/browse/AXIS-1525?page=comments#action_66670 ] Michael Thome commented on AXIS-1525: -------------------------------------
I'm not really sure what the right answer is, here. IMHO, having classes for groups wasn't so bad, but it was certainly terrible that the wire protocol was broken. I don't see an obvious way to avoid some sort of intermediate class here without losing information. E.g. my current workaround is to change the schema to be a sequence of a[0-n], b[0-n], c[0-n]... but this obviously loses the ability to represent a sequence of intermixed elements where order matters (e.g. abac != aabc). I guess I'd suggest that the codegen phase ought to warn about instances where group *occurs != 1 Long term, it probably takes doing to right thing in de/serialization to implement the required functionality. > xsd:group behavior is wrong > --------------------------- > > Key: AXIS-1525 > URL: http://issues.apache.org/jira/browse/AXIS-1525 > Project: Axis > Type: Bug > Components: Serialization/Deserialization > Versions: 1.2 Beta > Reporter: Steve Green > Fix For: 1.2.1 > Attachments: 1525.diff, SomeType.java, another.wsdl, group.patch, > groupgen.patch, sample.wsdl, test.wsdl.groups.tar > > WSDL2Java generates separate types for groups, and objects that reference > groups end up with a children object. The problem is that serialization of > that object should not show the group in XML. The elements of the group > should appear on the wire as if they were elements of the referencing object. > It seems that the problem might be fixable by changing the way in which > WSDL2Java generates classes with groups. The bean writer could recurse in to > groups and treat the elements as elements of the object being written. This > might create problems when trying to properly handle xsd attributes like > minOccurs=0, etc.. that appear on the group reference. > Another possible solution would be to add some info to the type description > so that the serialization could could recognize a group reference and do the > right thing. The same would need to be true of the deserializer. This fix > involves a change to the code generator as well as changes to the Axis engine. > N O T E: I am interested in supplying a fix for this problem. Please > comments on this issue so that I chose the method that best fits the design > goals of the Axis developers. -- 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
