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: [email protected]
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):
