DO NOT REPLY [Bug 23731] New: - Impossible to specify code gen. location for holders of arrays of predefined XSD and SOAPENC types

[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=23731>.
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=23731

Impossible to specify code gen. location for holders of arrays of predefined XSD and SOAPENC types

           Summary: Impossible to specify code gen. location for holders of
                    arrays of predefined XSD and SOAPENC types
           Product: Axis
           Version: current (nightly)
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: WSDL processing
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: Andrei.Iltchenko@nl.compuware.com


The way WSDL2Java is currently written makes it impossible to specify where 
holders for arrays of predefined XSD and SOAPENC type that map on primitive 
Java types or their wrappers are generated in the case of the "wrapped" style 
document/literal web services.

Currently such holders are always generated in either 
directory 'java/lang/holders' or 'holders' regardless of whether the user has 
supplied a mapping for the XML Schema or the SOAPENC namespace to desired Java 
packages.

For example, given that 'DoExampleResponse' is referenced from the output 
parameter of a document/literal operation, the following piece of code:

  <element name="DoExampleResponse">
    <complexType>
      <sequence>
        <element name="ret" nillable="true" type="xsd:base64Binary"/>
        <element name="out" maxOccurs="unbounded" type="xsd:long"/>
        <element name="third" maxOccurs="unbounded" type="typens:arrayOfNil"/>
      </sequence>
    </complexType>
  </element>

<message name="DoExampleResponse">
  <part name="result" element="typens:DoExampleResponse"/>
</message>

will create a class 'holders.longArrayHolder' always in the package 'holders'.

If the second element of the complex type read
        <element name="out" nillable="true" maxOccurs="unbounded" 
type="xsd:long"/>
the class of the holder would be 'java.lang.holders.LongArrayHolder' and it 
would be created in the package 'java/lang/holders'.

This poses problems when there's a need to make sure that WSDL2Java generates 
code at a predictable location.

The attached patch lifts this limitation and allows the user to influence the 
place where such holders are generated by associating the XML Schema or the 
SOAPENC namespace with a given Java package name.