RE: Bug with Arrays as Return Types
Hello, I'm also not familiar with Axis internals... When migrating an application from Axis 1.1 to 1.2.1, the .Net started to throw an exception with the array parameters. After some tries of making manual soap requests (with the soap packets generated by Axis1.1 and 1.2) to .Net I found that if the xsi:type attribute came first, the .Net didn't throw the exception. So what I did was to get the ArraySerializer.java code from Axis 1.2.1, update it in order to process first the xsi:type attribute, and extended the WSDL2Java in order to generate stubs that use my own ArraySerializerFactory: qName = new javax.xml.namespace.QName... cachedSerFactories.add(new altitude.integrationServer.encoding.ser.ArraySerializerFactory(qName, qName2)); cachedDeserFactories.add(new org.apache.axis.encoding.ser.ArrayDeserializerFactory()); I am not a SOAP expert, I think this is more a .Net issue (the order of attributes shouldn't be relevant), but it would be nice for Axis to continue to interoperate out-of-the-box with .Net. Cheers, Duarte -Original Message- From: Andrew Vardeman [mailto:[EMAIL PROTECTED] Sent: quinta-feira, 23 de Junho de 2005 19:54 To: axis-user@ws.apache.org Subject: RE: Bug with Arrays as Return Types Duarte, Thanks for your replies on- and off-list. It took me a bit to follow what you were saying. I'm not very familiar with Axis internals, and I've never tried to build the source. Do you mean that your fix causes Axis to serialize the array as it did in 1.1, or just that switching the attribute order makes the new format readable by .NET? What I mean is, will my .NET client, unmodified, understand arrays sent back from Axis 1.2 with this change? Should this be filed as a bug report, and if so, does one already exist? Thanks in advance, Andrew At 04:12 AM 6/23/2005, you wrote: Hello, With Axis 1.1 you have: ... xsi:type=soapenc:Array soapenc:arrayType=xsd:string[3] ... With Axis 1.2 you have: ... soapenc:arrayType=soapenc:string[3] xsi:type=soapenc:Array I have updated the ArraySerializer.java in order to change the order of the attributes (xsi:type=soapenc:Array must come first) and it seems to work with .Net Duarte -Original Message- From: Andrew Vardeman [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 22 de Junho de 2005 21:59 To: axis-user@ws.apache.org Subject: Re: Bug with Arrays as Return Types I've put together two webapps for comparision: one using Axis 1.1, the other using Axis 1.2. They can be downloaded here: http://www.public.iastate.edu/~andrewv/axis/webapps.zip They each have one service, StringArrayServer. In each case, the service is implemented by a Java class with one method: String[] getStringArray(); Each service is deployed via the AdminClient with the following deploy.wsdd: deployment name=test xmlns=http://xml.apache.org/axis/wsdd/; xmlns:java=http://xml.apache.org/axis/wsdd/providers/java; xmlns:xsi=http://www.w3.org/2000/10/XMLSchema-instance; service name=StringArrayServer provider=java:RPC parameter name=scope value=request/ parameter name=className value=StringArrayServer/ parameter name=allowedMethods value=*/ /service /deployment The two versions of Axis generate nearly identical WSDL files for the services via the ?wsdl query in the URL. When a request is made, Axis 1.1 returns this XML: ?xml version=1.0 encoding=UTF-8? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns1:getStringArrayResponse soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/; xmlns:ns1=http://DefaultNamespace; ns1:getStringArrayReturn xsi:type=soapenc:Array soapenc:arrayType=xsd:string[3] xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/; itemstring 1/item itemstring 2/item itemstring 3/item /ns1:getStringArrayReturn /ns1:getStringArrayResponse /soapenv:Body /soapenv:Envelope Axis 1.2 returns this XML, which fails to work with a .NET client built from the WSDL generated by the ?wsdl comand: ?xml version=1.0 encoding=utf-8? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns1:getStringArrayResponse soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/; xmlns:ns1=http://DefaultNamespace; getStringArrayReturn soapenc:arrayType=soapenc:string[3] xsi:type=soapenc:Array xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/; getStringArrayReturn xsi:type
Bug with Arrays as Return Types
Title: Bug with Arrays as Return Types Hi, I've got a Problem with web service methods returning an array. I have found the example from http://wiki.apache.org/ws/DotNetInteropArrays and it says: At one point, there was a bug in AXIS dealing with an operation that returns an array directly, rather than a structure containing an array (ie, an operation like String[] getInfo() rather than Container getInfo()). This may still be present in AXIS V1.2RC3. Dims? Another thread in the archive says: Also make sure that you've applied the fix for the bug that Dino talks about. I have installed AXIS 1.2.1 and the bug still seems to be present. Is this true? If so: Where can I find a patch or a workaround? Please help! Mit freundlichen Grüßen Dipl. Ing. Oliver Wolters (Systementwickler Auftragsentwicklung) -- ProCom Systemhaus und Ingenieurunternehmen GmbH Luisenstr. 41 - D-52070 Aachen Tel. +49 241 51804-175 Fax +49 241 51804-30 http://www.procom.de mailto:[EMAIL PROTECTED]
Re: Bug with Arrays as Return Types
Oliver, Can you please open a bug report and upload the WSDL you use to generate the server/client. thanks, dims On 6/22/05, Wolters, Oliver [EMAIL PROTECTED] wrote: Hi, I've got a Problem with web service methods returning an array. I have found the example from http://wiki.apache.org/ws/DotNetInteropArrays and it says: At one point, there was a bug in AXIS dealing with an operation that returns an array directly, rather than a structure containing an array (ie, an operation like String[] getInfo() rather than Container getInfo()). This may still be present in AXIS V1.2RC3. Dims? Another thread in the archive says: Also make sure that you've applied the fix for the bug that Dino talks about. I have installed AXIS 1.2.1 and the bug still seems to be present. Is this true? If so: Where can I find a patch or a workaround? Please help! Mit freundlichen Grüßen Dipl. Ing. Oliver Wolters (Systementwickler Auftragsentwicklung) -- ProCom Systemhaus und Ingenieurunternehmen GmbH Luisenstr. 41 - D-52070 Aachen Tel. +49 241 51804-175 Fax +49 241 51804-30 http://www.procom.de mailto:[EMAIL PROTECTED] -- Davanum Srinivas -http://blogs.cocoondev.org/dims/
AW: Bug with Arrays as Return Types
=myNS:EUserLoggedIn xmlns:myNS=http://gateway.bofit.enw.procom.de; languageSpecificType=java:de.procom.enw.bofit.base.EUserLoggedIn/ beanMapping qname=myNS:EWrongPassword xmlns:myNS=http://gateway.bofit.enw.procom.de; languageSpecificType=java:de.procom.enw.bofit.base.EWrongPassword/ beanMapping qname=myNS:EUnknownDomain xmlns:myNS=http://gateway.bofit.enw.procom.de; languageSpecificType=java:de.procom.enw.bofit.base.EUnknownDomain/ beanMapping qname=myNS:EDbError xmlns:myNS=http://gateway.bofit.enw.procom.de; languageSpecificType=java:de.procom.enw.bofit.base.EDbError/ parameter name=allowedMethods value=getUserDomainsByName, createServiceManager, logoutWebservice/ /service When generating Client-Stubs for VB the getUserDomainsByName-Methode has the return type TDomain - not TDomain[] (or Variant in VB). Please, could you give me a hint what's going wrong here? Regards Oliver Wolters -Ursprüngliche Nachricht- Von: Davanum Srinivas [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 22. Juni 2005 14:19 An: axis-user@ws.apache.org Betreff: Re: Bug with Arrays as Return Types Oliver, Can you please open a bug report and upload the WSDL you use to generate the server/client. thanks, dims On 6/22/05, Wolters, Oliver [EMAIL PROTECTED] wrote: Hi, I've got a Problem with web service methods returning an array. I have found the example from http://wiki.apache.org/ws/DotNetInteropArrays and it says: At one point, there was a bug in AXIS dealing with an operation that returns an array directly, rather than a structure containing an array (ie, an operation like String[] getInfo() rather than Container getInfo()). This may still be present in AXIS V1.2RC3. Dims? Another thread in the archive says: Also make sure that you've applied the fix for the bug that Dino talks about. I have installed AXIS 1.2.1 and the bug still seems to be present. Is this true? If so: Where can I find a patch or a workaround? Please help! Mit freundlichen Grüßen Dipl. Ing. Oliver Wolters (Systementwickler Auftragsentwicklung) -- ProCom Systemhaus und Ingenieurunternehmen GmbH Luisenstr. 41 - D-52070 Aachen Tel. +49 241 51804-175 Fax +49 241 51804-30 http://www.procom.de mailto:[EMAIL PROTECTED] -- Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Bug with Arrays as Return Types
I've put together two webapps for comparision: one using Axis 1.1, the other using Axis 1.2. They can be downloaded here: http://www.public.iastate.edu/~andrewv/axis/webapps.zip They each have one service, StringArrayServer. In each case, the service is implemented by a Java class with one method: String[] getStringArray(); Each service is deployed via the AdminClient with the following deploy.wsdd: deployment name=test xmlns=http://xml.apache.org/axis/wsdd/; xmlns:java=http://xml.apache.org/axis/wsdd/providers/java; xmlns:xsi=http://www.w3.org/2000/10/XMLSchema-instance; service name=StringArrayServer provider=java:RPC parameter name=scope value=request/ parameter name=className value=StringArrayServer/ parameter name=allowedMethods value=*/ /service /deployment The two versions of Axis generate nearly identical WSDL files for the services via the ?wsdl query in the URL. When a request is made, Axis 1.1 returns this XML: ?xml version=1.0 encoding=UTF-8? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns1:getStringArrayResponse soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/; xmlns:ns1=http://DefaultNamespace; ns1:getStringArrayReturn xsi:type=soapenc:Array soapenc:arrayType=xsd:string[3] xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/; itemstring 1/item itemstring 2/item itemstring 3/item /ns1:getStringArrayReturn /ns1:getStringArrayResponse /soapenv:Body /soapenv:Envelope Axis 1.2 returns this XML, which fails to work with a .NET client built from the WSDL generated by the ?wsdl comand: ?xml version=1.0 encoding=utf-8? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body ns1:getStringArrayResponse soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/; xmlns:ns1=http://DefaultNamespace; getStringArrayReturn soapenc:arrayType=soapenc:string[3] xsi:type=soapenc:Array xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/; getStringArrayReturn xsi:type=soapenc:stringstring 1/getStringArrayReturn getStringArrayReturn xsi:type=soapenc:stringstring 2/getStringArrayReturn getStringArrayReturn xsi:type=soapenc:stringstring 3/getStringArrayReturn /getStringArrayReturn /ns1:getStringArrayResponse /soapenv:Body /soapenv:Envelope Is this considered a bug or just the new intended behavior? Thanks, Andrew At 10:48 AM 6/22/2005, you wrote: Oliver, I think I have a problem similar to yours. I had an RPC service written in Java from which I generated WSDL that was consumed by a .NET client. The client is in use, so I can't change the interface now. Upgrading to Axis 1.2 from 1.1 changes how arrays of Strings get returned to the .NET client--so I can't upgrade to Axis 1.2 without breaking the current system and making changes on the client. Like you, I know I'm doing things somewhat backward (going from Java to WSDL rather than the other way around). Is backward compatibility for this sort of scenario simply not a goal of Axis? Can any developers comment? Thanks, Andrew ***original message*** Hi Dims, thanks for your answer. I think that there is already a bug report for this bug (if \ it's stil present). I'm not sure but maybe I'm doing something bad with my \ deployment. The problem is: The webservices I'm working on are generated from \ CORBA-IDL - not from a WSDL as I have explained in my mail AXIS 1.2 and MS VB \ interop (arrays) So the way it goes is CORBA-IDL - idlj- Java-Stubs - deploy as \ WS - generate WSDL - generate Client-Stub. The generated WSDL is (the getUserDomainsByName-Methode returning an Array of \ TDomain makes trouble):
