axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jongjin Choi" <gunsn...@hotmail.com>
Subject Re: [jira] Commented: (AXIS-1547) Document/Literal wrapped response creates wrong SOAP envelope root element in response message.
Date Tue, 22 Feb 2005 02:13:02 GMT
Dims, Glen, Tom and all,

There are serveral postings in axis-user list about wrapped-literal array usages.
Currently we generate bare array schema for the bean which has indexed getter/setter methods.
(#4 below)
The problem comes from the wrapped array schema generated from the beans which hasn't
indexed getter/setter methods. (#3 below)

I think we should generate bare array schema for #3 also. 
Why should we generate the wrapped array schema for this case? Any special reason?

This change will break the generated WSDL's backward compatibility. 
(ie. WSDL generated from same java interface/bean is not same after this changes - NO ArrayOfXXX
complextype)
We can switch this by appropriate flag. (TypeMappingVersion or something else)

Thought?

/Jongjin

----- Original Message ----- 
From: "Jongjin Choi (JIRA)" <axis-dev@ws.apache.org>
To: <axis-dev@ws.apache.org>
Sent: Monday, February 21, 2005 8:11 PM
Subject: [jira] Commented: (AXIS-1547) Document/Literal wrapped response creates wrong SOAP
envelope root element in response message.


>     [ http://issues.apache.org/jira/browse/AXIS-1547?page=comments#action_59497 ]
>     
> Jongjin Choi commented on AXIS-1547:
> ------------------------------------
> 
> Hi, Bill.
> 
> I think this issue is somewhat related to your recent email.
> (http://www.archivum.info/axis-user@ws.apache.org/2005-02/msg00443.html)
> 
> AFAIK, Axis can handle two cases - wrapped array and bare array - in wrapped literal
mode.
> 
> At the server side, appropriate information should be provided by
> WSDD and/or _Helper classes (_Helper's method can be embeded into ValueType calsses).
> At the client side, all the information is generated into stub impl classes.
> 
> Let's concentrate on the server side....
> 
> If the wrapped array is used in WSDL(#1 below), we need to run WSDL2Java with --server-side
and --helpGen option and the generated _Helper classes and deploy.wsdd should be used in deployment
along with the web service impl classes. 
> 
> #1 : wrapped array
>  <s:complexType name="Container">
>    <s:sequence>
>      <s:element minOccurs="1" maxOccurs="1" name="param1" nillable="true" type="s:string"
/>
>      <s:element minOccurs="1" maxOccurs="1" name="wrapper" nillable="true" type="tns:ArrayOfString"
/>
>    </s:sequence>
>  </s:complexType>
>  <s:complexType name="ArrayOfString">
>    <s:sequence>
>      <s:element minOccurs="0" maxOccurs="unbounded" name="param2" type="s:string"
/>
>    </s:sequence>
>  </s:complexType>
> 
> If you look at the deploy.wsdd generated by wsdl2java, we'll find that 'ArrayOfString'
should be (de)serialized with Bean(De)Serializer not Array(De)Serializer. (.i.e. ArrayOfString
and/or ArrayOfString_Helper is needed)
> 
> 
> If the bare array is used in WSDL(#2 below), we need to specify approprite information
in <operation> and <typeMapping> in *ONLY* WSDD file.
> 
> #2 : bare array
> <s:complexType name="Container">
>  <s:sequence>
>    <s:element minOccurs="1" maxOccurs="1" name="param1" nillable="true" type="s:string"
/>
>    <s:element minOccurs="0" maxOccurs="unbounded" name="param2" type="s:string" />
>  </s:sequence>
> </s:complexType>
> 
> *  #1, #2 is an excerpt from Dino Chiesa's mail. 
> 
> I think the problems are :
> (1) The use of wrapped-literal array is not documented well. 
>    (If I missed some documents, pls, let me know)
>    But we can do it without interop problem (also with .NET). 
> 
> (2) Axis generates wrapped array wsdl on the fly which it cannot support without _Helper
classes.
>   
>   When the class is somewhat like:
>    #3:
>     class A {
>        String[] arr;
>        int b;
> 
>        public String[] getArr() { return arr; }
>        public void setArr(String[] arr) { this.arr = arr; }
>        // getB/setB is omitted for brevity
>     }
> 
>   The "ArrayOfString" complex type is generated in the WSDL but when starting from Java,

>   the axis users will not provide the ArrayOfString.java classes usually.
>   The class should be generated from WSDL file. 
>   (Two step is required. java2wsdl first, wsdl2java second).
> 
>   But if we modify the class like this :
>    #4:
>     class A {
>        String[] arr;
>        int b;
> 
>        public String[] getArr() { return arr; }
>        public void setArr(String[] arr) { this.arr = arr; }
>        
>        public String getArr(int i) { return arr[i]; }      // ADDED
>        public void setArr(int i, String s) { arr[i] = s; } // ADDED
>        // getB/setB is omitted for brevity
>     }
> 
>   The wsdl generated will not contain wapped array complex type (ArrayOfString).
>   Instead, we will get a wsdl using bare array.
> 
>   The JAX-RPC spec is not clear about this. But I think the axis should generate 
>   bare array WSDL not only #4 but also #3. If so, the axis users can deploy web service
>   using wrapped-literal array by only providing WSDD. (without running wsdl2java for
ArrayWrapper and _Helper classes.)
> 
> In both case, I think, some tool supports(Java2WSDD or something?) may make the axis-user's
life simpler.
> 
> Thanks.
> 
> /Jongjin
> 
> 
> 
> 
> 
>> 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
> 
>
Mime
View raw message