Problem with return of javax.xml.transform.Source impl from webService

Question

I have a web services that needs to return an XML string to the calling client. If I return the XML as a String object it gets deserialized twice and the end result is no longer XML. My research indicates that I can return an implementation of javax.xml.transform.Source and this will cause SOAP to attach the XML string to the message rather than embed it (protecting it from deserialization). The following is the effective part of my method:
public Source[] consumeTextMessage(String id) throws RemoteException {
try {
MessageConsumer mc = new MessageConsumer();
String[] messages = mc.consumeTextMessage(id);
StreamSource[] sources = new StreamSource[messages.length];
for(int i = 0; i < messages.length; i++) {
sources[ i ] = new StreamSource();
return sources;
} catch(RemoteException e) {
throw e;
note: the mc.consumeTextMessage(id) call works correctly and I know that I'm not putting anything in the StreamSource objects in the loop to build the array of StreamSource objects - just trying to get SOMETHING to work
so this deploys without problem, but when I try to get a wsdl for the webservice i get a Server 500 error; the log says this:
javax.servlet.ServletException: WSDL Generation exception: java.lang.Exception javax.xml.transform.Source is an abstract class: cannot be instanciated
ok.... if I change the method return type to a concrete class (StreamSource[]), redeploy and try to get a wsdl, I get this absolutely crazy error:
javax.servlet.ServletException: WSDL Generation exception: java.lang.Exception java.io.Reader is an abstract class: cannot be instanciated
I have NO clue why it thinks it needs a Reader.
If I change the method return type to String[] (and make the various adjustments to the method) then it deploys ok and gives me a good WSDL (though it still doesn't work because the Strings are deserialized twice so this isn't a viable solution but it does show that my webservice config is correct).
So... bottom line seems to be that the webService "engine" of 10g AS doesn't like Source or StreamSource.....
Any ideas what I can do??

Answer 1

Funny story here: trying to deploy a different webserivce all together and got the same error message; thought I remembered seeing it before but wasn't sure; did a google search on it and lo and behold came across my first posting in this thread.... crazy.
Anyway, I have discovered something that answers some of the questions I had in my first post: It seems that the argument types used in a webservice signature MUST be CONCRETE classes (and I would think primitives would work too though I don't remember trying them) - they can not be Interfaces or abstract classes. Probably if I read the webservices spec it would tell me that.
So the error I was getting before was because Source was not a concrete class, and presumably the second error was caused by some signature somewhere along the line using the Reader abstract class.
Fun stuff.