[ 
http://issues.apache.org/jira/browse/AXIS-1525?page=comments#action_66658 ]
     
Steve Green commented on AXIS-1525:
-----------------------------------

fwiw, I agree with you about "1.2RC3's wsdl2java wrote (IMHO) closer to correct 
looking classes, even with the group classes... Of course, serialization with 
these constructs was totally broken."

Furthermore, that fact that AnotherType doesn't have any members is clearly a 
problem.  But what if it did?  Would that satisfy things for you?

When I came across this problem, I considered 2 different ways to solve it.  
One way (the one I chose) was to treat group refs as a sort of macro.  The 
other way was to deal with this during {de}serialization.  The latter was more 
appealing wrt the object model, however much more difficult to implement.

In my world, sending the proper xml over the wire greatly outweighs what 
unpatched axis did.

Unless the "macro" method is being deemed as unacceptable, I will look into the 
problem with AnotherType.java.

> 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

Reply via email to