[ 
http://issues.apache.org/jira/browse/AXIS-1547?page=comments#action_59566 ]
     
Bill Keese commented on AXIS-1547:
----------------------------------

I guess that the wrapped/bare array portion of this bug report is just a 
misunderstanding of how Axis works.

Basically, people expected wrappers in their xml:

<foo>
   <b>123</b>
   <myArray>
       <item>...</item>
       <item>...</item>
   </myArray>
</foo>

BUT they _didn't_ expect wrappers in their java code:

class foo {
  int b;
  String[] myArray;
};


People were hand-writing both the WSDL and the Java classes, rather than 
running WSDL2Java .  If you read 
http://marc.theaimsgroup.com/?l=axis-user&m=109587276631028&w=2 that must be 
the cause of the misunderstanding, right?

So, the conclusion is that you need to use the ArrayOfString java class.  But, 
that seems like unnecessary overhead.  The behavior above is more convenient.  
And also, I expected
the WSDL below:

      <element name="GetEmployeeNames">
       <complexType/>
      </element>
      <element name="GetEmployeeNamesResponse">
       <complexType>
        <sequence>
          <element name="GetEmployeeNamesReturn" type="tns:ArrayOfString"/>
        </sequence>
       </complexType>
      </element>

... to simply map to
 
    String[] GetEmployeeNames()

... rather than the more complicated

    ArrayOfString GetEmployeeNames()

Is that possible?

PS: Note also that this bug addresses two other issues (besides wrapped/bare 
arrays)

> Document/Literal wrapped response creates wrong SOAP envelope root element in 
> response message.
> -----------------------------------------------------------------------------------------------
>
>          Key: AXIS-1547
>          URL: http://issues.apache.org/jira/browse/AXIS-1547
>      Project: Axis
>         Type: Bug
>   Components: WSDL processing, Serialization/Deserialization
>     Versions: beta-2
>  Environment: WSDL, Windows XP, J2EE 1.3
>     Reporter: Eric Chijioke
>     Assignee: Glen Daniels
>  Attachments: array.zip
>
> I sent this (accidentally) to axis-user list.
> I received a response from Ane Thomas Manes indicating tht I should file this 
> as a bug:
> I am currently using Axis 1.2 beta to expose my web service. 
> I am using the document/literal (wrapped) configuration. 
>  
> The axis server does something that seems strange, and I'm not sure if it's 
> intentional or not. This email is not as long as it seems.  
>  
>  
> Given this operation (defined in my WSDL):
> <operation name="getFactor">
>     <input name="getFactorRequest" message="impl:getFactorIn"/>
>     <output name="getFactorResponse" message="impl:getFactorOut"/>
> </operation>
> ---------------------------------------------------------------------------------
>  
> The corresponding input and output messages are defined a follows:
> <message name="getFactorIn">
>     <part name="parameters" element="intf:getFactor"/>
> </message>
> <message name="getFactorOut">
>     <part name="parameters" element="intf:getFactorResponse"/>
> </message>
> ---------------------------------------------------------------------------------
>  
>  
> The corresponding elements are defined as follows:
> <element name="getFactor">
>     <complexType>
>         <sequence>
>             <element minOccurs="1" maxOccurs="1" name="id" type="xsd:string"/>
>            </sequence>
>     </complexType>
> </element>
> <element name="getFactorResponse">
>     <complexType>
>         <sequence>
>             <element name="factor" minOccurs="1" maxOccurs="1" 
> type="intf:Factor"/>
>         </sequence>
>     </complexType>
> </element>
> ---------------------------------------------------------------------------------
>  
> I won't bother providing the schema for the intf:Factor type.
>  
> Here's the question:
> When a client calls the getFactor() method, why does the response always 
> contain a top level element in the soap body call getFactorReturn instead of 
> using the name provided in the getFactorResponse element schema: in this case 
> "factor"? 
>  
> So the response to this method looks like this (the top level element of the 
> body tag is <getFactorReturn>):
>  
> <?xml version="1.0" encoding="utf-8"?>
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/ 
> <http://schemas.xmlsoap.org/soap/envelope/> " 
> xmlns:xsd="http://www.w3.org/2001/XMLSchema 
> <http://www.w3.org/2001/XMLSchema> " 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance 
> <http://www.w3.org/2001/XMLSchema-instance> ">  <soapenv:Body>
>   <getFactorResponse xmlns="http://object.hydra.erisk.com 
> <http://object.hydra.erisk.com/> ">
>    <getFactorReturn>
>     <name>My Test Factor</name>
>     <id>1</id>
>    </getFactorReturn>
>   </getFactorResponse>
>  </soapenv:Body>
> </soapenv:Envelope>
>  
> I would have expected the response to this method to look like this (the top 
> level element of the body tag is <factor>):
>  
> <?xml version="1.0" encoding="utf-8"?>
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/ 
> <http://schemas.xmlsoap.org/soap/envelope/> " 
> xmlns:xsd="http://www.w3.org/2001/XMLSchema 
> <http://www.w3.org/2001/XMLSchema> " 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance 
> <http://www.w3.org/2001/XMLSchema-instance> ">  <soapenv:Body>
>   <getFactorResponse xmlns="http://object.hydra.erisk.com 
> <http://object.hydra.erisk.com/> ">
>    <factor>
>     <name>My Test Factor</name>
>     <id>1</id>
>    </factor>
>   </getFactorResponse>
>  </soapenv:Body>
> </soapenv:Envelope>
>  
> The reason this is an issue is that when you auto generate code (at least in 
> .NET) using the WSDL I described above, it assumes (rightly so?) that the top 
> level element of the response SOAP body will be named as you name it in your 
> WSDL. 
>  
> Please let me know if this is an issue with Axis or if there is a spec 
> somewhere that requires the top level element to be named getFactorReturn (in 
> this case).
> Thank You,
> Eric Chijioke

-- 
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
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Reply via email to