I would like to point out a few issues regarding the WSDL2Java code
generation :
1. the stub generated has the following code fragments:
public returnType operation1(ParamType param2) throws
java.rmi.RemoteException{
org.apache.axis2.client.OperationClient _operationClient =
_serviceClient.createClient(_operations[1].getName());
_operationClient.getOptions().setAction("");
_operationClient.getOptions().setExceptionToBeThrownOnSOAPFault(true);
The generated code did a setAction("") in the stub method. So even if I
try to get the serviceClient and did a setAction to whatever SOAP
operation I want to invoke, it will be overridden when I actually called
the stub method.
In previous (at least in 0.93 version) version, I was able to get a
client option and setAction accordingly.
2. In the generated stub and XXXMessageReceiverInOut ( for the server
side), the code generated for fromOM() method did a
param.getXmlStreamReaderWithoutCache().
The XmlStreamReaderWithoutCache when passed to the XmlBean's parse()
method, causes it to throw exception when parsing certain XML document.
When I changed them to getXmlStreamReader(), they work just fine !
3. For WSDL2Java, there is no switch (at least not documented), to say
whether I want to generate both a stub and a server-side code. I
generate the stub code by not having the switch -ss.
4. Also, it will be good if we can specify the namespace-package mapping
for all the generated java types. For example, if I am using Xmlbean
databinding for wsdl2java, it should be able to read the .xsdconfig file
that allow us to map namespace to arbitratry java package name.
Currently the wsdl2java only allow you to specify the package for the
generated stub/skeleton/ classes with the -p switch. (the .xsdconfig is
useful especially we have namespace like urn:xx:yy:1.0, which is quite a
common and recommended way of specifying schema namespaces with version.
In the default xmlbeans behaviour, it will generate some ugly package
name like _0_1_yy.yy or whatever.
Best Rgds
Kheng Kok
