The answer to this is that you could actually use wsdl2java to generate better code. Lets take an example scenario. For this I will be using a Service that I have deployed on Mooshup.com. This simple service has a operation called demo which accepts three parameters (firstParam, secondParam and thirdParam). I will be using the wsdl of this service for explanation. Lets first try to use wsdl2java on this wsdl and see what happens and how -uw can help.
If i was to generate a stub for this using the following command,
sh wsdl2java.sh -uri http://mooshup.com/services/keith/DemoService?wsdl -o /home/keith/projects/demo
I would have to use this stub as follows,
DemoServiceStub stub = new DemoServiceStub();
DemoServiceStub.Demo demo = new DemoServiceStub.Demo();
DemoServiceStub.DemoType demoType = new DemoServiceStub.DemoType();
demo.setDemo(demoType);
demoType.setFirstParam("firstParam");
demoType.setSecondParam(10.0);
demoType.setThirdParam(true);
stub.demo(demo);
Now this does not look too elegant, but if I were to generate code using the -uw option with the following command,
sh wsdl2java.sh -uri http://mooshup.com/services/keith/DemoService?wsdl -o /home/keith/projects/demo -uw
I would be able to use the stub as,
DemoServiceStub stub = new DemoServiceStub();
stub.demo("firstParam", 20.0, true);
Now what is more elegant and easier? Its a easy answer.
The secret to this lies in the schema. You wont be able to generate easy to use stubs such as this all the time. What gets unwrapped (when -uw is used) is the sequence within the complex type. In our case the schema was as follows,
<xs:complexType name="demoType">
<xs:sequence>
<xs:element name="firstParam" type="xs:string" />
<xs:element name="secondParam" type="xs:double" />
<xs:element name="thirdParam" type="xs:boolean" />
</xs:sequence>
</xs:complexType>
<xs:element name="demo" type="ws:demoType" />
So the bottom line is use the -uw option when generating code with wsdl2java, this would generate code that is easy to use. (This should have been the default in wsdl2java ;))
Most users are not aware of the set of options that wsdl2java offer (Will cover that in another post).
5 comments:
I think that when the part name in the WSDL is "parameters" then by convention it is doc/lit/wrapped. Maybe the flag can be implicitly added in such cases?
Yes it will be good default it such a manner, but as for now you got to use -uw explicitly. The default is to generated wrapped types.
This was exactly was I was looking for! I'm primarily a .NET programmer, and using WCF I am used to the way that Visual Studio wraps up their classes. I started working with Axis2 and found the wsdl2java tool to be very obscure in its class generation. I started looking for a different tool altogether to make the java web service proxy code more like the .NET WCF code. Instead, your method does exactly what I need. Thanks!
Thanks, great post.
One question :
I faced some ridiculous situation when I used -uw options.
I'm working on SugarCRM. When I create stubs using -u -d xmlbeans, everything's proper.
But, when I create stubs using -uw -d xmlbeans, all the basic methods in the stub are missing return type.
Even the login() returns void, which is supposed to return some holder of sessionId.
'-uw' does not work for xmlbeans databinding?
hi
I am trying to generate stub via ADB method. But when i am running build.xml it is giving me following error.
gen_wsdl_stub:
[axis2-wsdl2java] Retrieving document at '{env.CCWSCA}/scripts/src/collections.wsdl'.
[axis2-wsdl2java] log4j:WARN No appenders could be found for logger (org.apache.axis2.i18n.ProjectResourceBundle).
[axis2-wsdl2java] log4j:WARN Please initialize the log4j system properly.
BUILD FAILED
/comabpusers/com/aim/mayankbi/bb/ccl9e/v77_5/build.xml:176: org.apache.axis2.wsdl.codegen.CodeGenerationException: Error parsing WSDL
No more specific error is being followed.
Post a Comment