DO NOT REPLY [Bug 12520] New: - Generated code for WSDL should not break object encapsulation

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12520>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12520

Generated code for WSDL should not break object encapsulation

           Summary: Generated code for WSDL should not break object
                    encapsulation
           Product: Axis
           Version: beta-3
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: WSDL processing
        AssignedTo: axis-dev@xml.apache.org
        ReportedBy: jesper.soderlund@smarttrust.com


The code that is generated for the type container classes could encourage good
programming practices, or maybe there should be a flag to WSDL2Java to enable
this behavior.

Now the generated code looks something like this for an XSD-element:

WSDL-snippet:
...
<xs:sequence>
   <xs:element name="aid" type="y:AIDType"/>
   <xs:element name="parameters" type="xs:hexBinary" minOccurs="0"/>
   <xs:element name="menuEntry" type="y:MenuEntry" minOccurs="0" maxOccurs="*"/>
</xs:sequence>
...

The generated code looks like this for the parameter element:
...
    public byte[] getParameters() {
        return parameters;
    }

    public void setParameters(byte[] parameters) {
        this.parameters = parameters;
    }
...

This would allow a client to accidentally alter the value after calling the
"setParameter" and then perhaps reusing the byte[]-object. It would be best
programming practice to do "System.arrayCopy" for these cases. The same goes for
 other Object types passed, in which case "clone" could be called instead of
arrayCopy. This will of course have some performance implications so it might be
best to put this behavior behind a command-line switch.