WSDL+Castor+complex schema = design or WSDL2Java issue

[Chris Kelly <ab...@tolstoy.com>]

I have a doc-lit service that mostly uses WSDL2Java-generated classes.

However, for a parameter to one method I use Castor instead of the Axis-generated 
classes. That parameter is defined in a large (1000+ lines), third-party schema. Let's 
call that parameter "BigParam".

To make things easier, I created a small schema containing a dummy version of 
BigParam.xsd that just contains a string. That means when I used WSDL2Java it 
only produces BigParam.java instead of producing dozens of unused classes and, 
more importantly, it also doesn't fill the ???Stub.java and the .wsdd file with 
serialization data for those unused classes.

However, the WSDL as then shown by hitting the ?WSDL URL for my service shows 
the dummy version of BigParam, not the real version.

Question #1: Would there be a way to have that ?WSDL URL provide a reference to 
the real version of BigParam? That way, I could keep things as they are and the 
WSDL would reflect the real service and its parameters.

Alternatively, I could give WSDL2Java the real version of BigParam. In that case, it 
would generated unused classes, but those can simply be discarded. However, it 
would also fill ???Stub.java and the .wsdd file with the serialization data mentioned 
above, and I'd need to then manually or perhaps with ant remove that.

Question #2: Can I tell WSDL2Java not to emit some of that serialization data?

Question #3: If Axis uses introspection to generate the ?WSDL URL, and I'm using 
Castor, what happens? The dummy BigParam.java, as generated by WSDL2Java, is 
not available to my web service AFAIK, yet that's what's being returned by the 
?WSDL URL.

Question #4: Should I keep things as they are now, just return my own WSDL from 
the "?WSDL" URL? That would be complicated as well, since my WSDL imports the 
BigParam schema and two others. Returning your own WSDL is described here: 
http://www.mail-archive.com/axis-user@xml.apache.org/msg07570.html

Question #4: So, what's the best way to deal with these kinds of issues?