On 2 Jul 2005, at 21:28, James Black wrote:
How can I get Axis to use the Java Collections classes? I see in
1.2.1's "What's in this release" section that it says "Automatic two-
way conversions between Java Collections and SOAP Arrays". I
don't see
any details, though. How do I use this?
Specifically, I'm playing with GoogleSearch.wsdl. The
GoogleSearchResult class AXIS has getResultElements() and
setResultElements() methods that deal with plain Java arrays -
ResultElement[]. I'd prefer collections objects like List or (for
Java
1.5) List<ResultElement>.
Is this what this snippet is describing? If not, what does it
mean? And
is there any way to do what I want?
What benefits would you get by sending the extra data that a
collection would require?
I'm not proposing a change to the WSDL or to what is sent over the wire.
If you send it as an array, and then the client can decide which way
to use the data, so if a hashmap would make sense for the client,
it can
be stored that way, but, not all clients have collection apis. For
example, if you use gsoap and a C client, you would need to use
arrays.
I'm asking if there's a way I can influence the Java representations
of SOAP data - both Java types fed into axis and Java types returned
from it.
Can I get a List<Foo> (an ArrayList<Foo>, perhaps) out of axis rather
than a Foo[]? And a Map<Foo,Bar> rather than a KeyValueBean[] or
whatever?
Since you bring up other language implementations, how about SOAPpy:
It can deal with Python dictionaries natively. Can Axis do that? If
not, why is it possible for SOAPpy and not Axis?
It is trivial to insert the array into a collection, and is simpler
and more interoperative to transfer arrays of items around than to try
to pass collections.
It's not as trivial when you have an entire graph of these objects to
deal with. It's certainly possible, but I don't understand why Axis
can't just give me what I want rather than requiring me to construct
an entirely new object graph and then discard then one that it gave me.
--
Scott Lamb <http://www.slamb.org/>
