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/";>
> <item>string 1</item>
> <item>string 2</item>
> <item>string 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:string">string 1</getStringArrayReturn>
> <getStringArrayReturn
>xsi:type="soapenc:string">string 2</getStringArrayReturn>
> <getStringArrayReturn
>xsi:type="soapenc:string">string 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):
