Jongjin, +1 to go ahead and make the change. Please make it such that it affects only typemapping version 1.3 for now.
thanks, dims On Tue, 22 Feb 2005 11:13:02 +0900, Jongjin Choi <[EMAIL PROTECTED]> wrote: > 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)" <[email protected]> > To: <[email protected]> > 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/[email protected]/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 > > > > -- Davanum Srinivas - http://webservices.apache.org/~dims/
