Back when I was a SOAP novice who didn't really understand what I was doing,
I declared an C++ interface that consisted of several structures like this:
struct collectionOfThings
{
struct thing* __ptr;
int __size;
};
I used gSOAP to create stub functions from that (in both C and C++), and a
WSDL file for my Java clients.
Now, this all works very well thank you. gSOAP is more than happy to encode
and decode multiple <item> elements for each 'thing' in my
'collectionOfThings'. Also, Apache AXIS clients and servers also happily
cope with collectionOfThings.
Unfortunately, other SOAP implementations aren't so tolerant. The reason for
this is that the WSDL entry for collectionOfThings doesn't state that it's a
complex structure of type "ENC:Array" - instead, it states that it's of type
"thing"... which the JAX-RPC wscompile utility (for example) dislikes.
So I changed the WSDL file (as recommended by a JAX-RPC mailing list member)
to accurately reflect what a collectionOfThings really is. Now the JAX-RPC
wscompile utility likes it... but the gSOAP server rejects incoming messages
because collectionOfThings isn't of type enc:Array [even though technically
it is].
Now... I think that what I should have done originally is called my
structure "ArrayOfthing" and then gSOAP would have behaved correctly.
Unfortunately, I'm now 9 months after the fact and have several live
services built on top of this mistake... which has only become apparent now
I'm trying to migrate away from AXIS onto JAX-RPC.
Is there /anything/ I can do either on the gSOAP or the JAX-RPC end to
persuade these APIs to talk to each other, or am I going to have to go
through the painful process of rebuilding the API the way it should have
been built in the first place? For example, is there a way to relax the
JAX-PRC wscompile utility to allow these 'loose' arrays, or a way to
persuade the gSOAP server to correctly handle the incoming array type for
something that really is an array?
Paul
This E-Mail and any attachment is intended only for the person or entity for
which it is addressed and may contain confidential material. If you are not
the addressee or have received this E-Mail in error, please inform the
sender immediately and delete it from your computer. In addition, if you are
not the addressee or have received this E-Mail in error, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
upon it is prohibited and may be unlawful.
If this E-Mail has been transmitted outside the ordinary course of its
business, the company for which the sender works accepts no liability for
any loss or damage suffered by any person arising from any use of or
reliance on information contained in this E-Mail, and any opinion expressed
in this E-Mail is personal to the sender and may not reflect the opinion of
such company. Although the network operator makes every reasonable effort to
keep its network free from viruses, neither the network operator nor the
sender or the company for which the sender works accepts any responsibility
for computer viruses transmitted through this E-Mail or any attachments; it
is your responsibility to virus scan this E-Mail and any attachments. Any
E-Mail reply to this address may be subject to interception or monitoring
for operational reasons or for lawful business practices.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net