I've used toArray() numerous times in my service code and had no problem with that. Obviously, Jim (the fellow who started this thread) doesn't have the luxury of coding that manually.
My point, to be more precise, is that JAX-RPC 1.0 says nothing about java.util collections classes/interfaces. Of course, Axis doesn't compromise its compliance with the JAX-RPC spec by providing functionality that extends the spec, but as a developer I am reluctant to use that extended functionality. Personally, I would prefer to see collections explicitly disallowed (Java2WSDL would throw an exception), so developers don't step in something they didn't see. But if collections are allowed, I would like to see that clearly documented. Naturally, if I would like to see something, I am free to produce it myself. But that goes back to my question: how does Axis 1.1 RC2 support java.util collections besides Java2WSDL's just blindly producing a generic Array complex type? The most I've read on this subject is a cryptic mention of the "--extraClasses" argument to Java2WSDL. Concerning "there is meant to be something in soap where you do say you are returning an Object and the type is passed in the envelope at run time." I don't understand how passing a type name in the SOAP envelope helps since the SOAP engine can dynamically build the SOAP message at request time anyway, and the SOAP engine still must fill in the XML Schema type's elements corresponding to the dynamically identified class' fields. Steve Loughran <[EMAIL PROTECTED]> wrote: Mitch Gitman wrote: > I'm still wondering about the apparent existing support for java.util.List and > the like. It seems to me that Java2WSDL should generate an exception when it > comes across a collection class that stores java.lang.Object instances. That is one thing wrong with collections; you cannot state in advance their type, and the thing at the far end cannot deal with arbitrary java objects. If you go return (Foo)list.toArray(new Foo[0]); You can turn a list to an array in a snap. A fromArray() would be nice to match it. However, there is meant to be something in soap where you do say you are returning an Object and the type is passed in the envelope at run time. I dont know the exact details...