I am using Axis 1.4 and this is very strange as I am reading forums
where they have reported this several versions back. Long time back
somebody has suggested a code change, but I am not sure it has made it
through as the latest Axis 1.4 has the same.
there is no solution yet?!?!
I would appreciate if somebody from Axis reads this and gives me a tip
how should we proceed.
Anybody else using arrays in the SOAP responses that are consumed by
.NET clients?
thanks a lot,
Stan
Anne Thomas Manes wrote:
If you have elementFormDefault="qualified", then the
<item> elements should be qualified.
Sounds like a bug.
On 6/4/06, Stanley
Stanev <[EMAIL PROTECTED]>
wrote:
Anne, yes, my schema has
elementFormDefault="qualified"
I can send you the whole WSDL if you want, but it is OK I think, the
Axis generates those <item xmlns="">...</item> and for some
reason it uses empty namespace xmlns="" for the item element that
represents an item of the array sent back to the SOAP consumer
any other ideas will be greatly appretiated!!!
there must be a way to exchange arrays with .NET clients, I just cannot
believe this problem does not have a solution
thanks a lot,
Stan
Anne Thomas Manes wrote:
Make sure that your schema specifies
elementFormDefault="qualified".
On 6/3/06, Stanley
Stanev <[EMAIL PROTECTED]
> wrote:
I
am pretty sure all my namespaces are correct, you are right that the
array items are part of the SOAP response, but .NET client does not
handle them correctly
What I am finding is that the part of the SOAP response looks something
like this:
...
<tickets>
<item xmlns="">...</item>
<item xmlns="">...</item>
<item xmlns="">...</item>
</tickets>
...
notice that Axis adds all those item elements and they have empty
namespace, so the .NET client skips them and does not add them to the
tickets array
I have read about this problem at some forums, but I have not gotten any
good solution
I really need to understand how we can handle this, I expect Axis to be
clever enough to allow us to have this correct.
Any idea how we can solve it?
thanks a lot,
Stan
Wolters, Oliver wrote:
>Hi Stanley,
>
>Your .NET Stub ist generated as expected (with arrays as return
types)? The xml-response from the server contains the right data (try
to use a SOAP-Monitor to validate this). But the elements of the array
are "null" when you try to access it in your client?
>
>Seems to me like you have the same problem that I had. In this case
you have a problem with your namespaces. If you post your wsdl, your
wsdd and a corresponding response message from the server, somebody on
the mailing list should be able to point out exactly what's wrong. I
changed a namespace in my wsdd-file, redeployed my service and
everything worked fine.
>
>Good luck ;-)
>Oliver Wolters
>
>--
>ProCom Systemhaus und
>Ingenieurunternehmen GmbH
>Luisenstr. 41 - D-52070 Aachen
>
>Tel. +49 241 51804-181
>Fax +49 241 51804-30
>http://www.procom.de
>mailto:[EMAIL PROTECTED]
>
>
>
>-----Ursprüngliche Nachricht-----
>Von: Stanley Stanev [mailto: [EMAIL PROTECTED]]
>Gesendet: Freitag, 2. Juni 2006 05:14
>An: [email protected]
>Betreff: Axis arrays and .NET problem
>
>
>I have deployed a web service under Axis 1.4 that returns an array
to
>the consumers of the service
>
>Axis clients work very well, however .NET clients does not get the
>elements of the array
>
>I have tried both document and wrapped styles of the services in
the WSDD:
>
>...<service name="TestService" provider="java:RPC"
style="document"
>use="literal">...
>
>and
>
>...<service name="TestService" provider="java:RPC"
style="wrapped"
>use="literal">...
>
>but still does NOT work
>
>any ideas are greatly appreciated!!!
>
>thanks,
>Stanley Stanev
>
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
----------------------------------------
Stanimir Stanev (Stanley)
Senior Java Developer
www.stanev.com
----------------------------------------
--
----------------------------------------
Stanimir Stanev (Stanley)
Senior Java Developer
www.stanev.com
----------------------------------------
|
