[Download] | [Documentation Home] | [Release Note]
For those of you who are more comfortable with the command line, these tools will be of great use. This guide contains instructions on generating a WSDL file from a Java class (Java2WSDL) and/or a set of Java class files from a WSDL (WSDL2Java) using these command line code generator tools.
This basic tool is implemented by the WSDL2Code class and for the convenience in the case of Java (which would be the majority) there is another WSDL2Java class. One can choose to run the main classes directly or use one of the scripts to run the WSDL2Code and WSDL2Java appropriately. The scripts are found in the bin directory of the WSO2 WSAS installation.
The script file to run this tool is located in WSO2WSAS_HOME/bin
Example : This example will cover the default scenario of generating the client stub using the WSDL to the specified output location. You can add other options listed on the Option References for WSDL2Java.
Windows : wsdl2java -uri %WSO2WSAS_HOME%\samples\CommodityQuote\wsdl\CommodityQuote.wsdl -o %WSO2WSAS_HOME%\output
Linux : ./wsdl2java.sh -uri $WSO2WSAS_HOME/samples/CommodityQuote/wsdl/CommodityQuote.wsdl -o $WSO2WSAS_HOME/output
Unlike WSDL2Java, Java2WSDL is the tool that generates a WSDL file out of a Java class file. Scripts for this tool are also included in the bin directory of the WSO2 WSAS installation.
The script file to run this tool is located in WSO2WSAS_HOME/bin
Example : This example will assume that you have set the SAMPLE_HOME environment variable as the base directory of the Java class. Under that we have test directory and inside that we have Math.class that we going to refer to, to generate the WSDL. You can add other options listed on the Option References for Java2WSDL
Windows : java2wsdl -cn test.Math -cp %SAMPLE_HOME% -o %WSO2WSAS_HOME%\output
Linux : ./java2wsdl.sh -cn test.Math -cp $SAMPLE_HOME -o $WSO2WSAS_HOME/output
Short Option | Long Option | Description |
-uri <Location of WSDL> | None | WSDL file location. This should point to a WSDL file in the local file system. |
-o <output Location> : | --output | Output file location. This is where the files would be copied once the code generation is done. If this option is omitted the generated files would be copied to the working directory. |
-l <language> | --language | Output language. Currently the code generator can generate code in Java but it has the ability to be extended to support other languages. |
-p <package name> | --package | The target package name. If omitted, a default package (formed using the target namespace of the WSDL) will be used. |
-a | --async | Generate code only for async style . When this option is used the generated stubs will have only the asynchronous invocation methods. It is switched off by default. |
-s | --sync | Generate code only for sync style . When this option is used the generated stubs will have only the synchronous invocation methods. It is switched off by default. When used with the -a option, this takes precedence. |
-t | --test-case | Generates a test case. In the case of Java it would be a junit test case. |
-ss | --server-side | Generates server side code (i.e. skeletons). Default is off. |
-sd | --service-description | Generates the service descriptor (i.e. server.xml). Default is off. only valid with -ss, the server side code generation option. |
-d | --databinding-method | Specifies the Databinding framework. Valid values are xmlbeans, adb, jibx, and none. Default is adb. |
-g | --generate-all | Generates all the classes. This option is valid only with the -ss (server side code generation) option. When on, the client code (stubs) will also be generated along with the skeleton. |
-u | --unpack-classes | Unpack classes. This option specifies whether to unpack the classes and generate separate classes for the databinders. |
-sn | --service-name | Specifies the service name to be code generated. If the service name is is not specified, then the first service will be picked. |
-pn | --port-name | Specifies the port name to be code generated. If the port name is is not specified, then the first port (of the selected service) will be picked. |
-ns2p | --namespace2package | Specifies a comma separated list of namespaces and packages where the given package will be used in the place of the auto generated package for the relevant namespace. The list will be in the format of ns1=pkg1,ns2=pkg2. |
-ssi | --serverside-interface | Generate an interface for the service skeleton. |
Apart from the above mentioned options one can pass extra options by prefixing them with -E (uppercase). These extra options will be processed by the extensions. The extra options that can be passed are documented separately with the extensions documentation (For example with ADB)
Short Option | Long Option | Description |
-cn <fully qualified class name> | --className | Fully qualified classname. This class and all dependent classes must be present in the classpath provided by -cp option. |
-o <output Location> : | --output | Output file location. This is where the generated WSDL file would be placed. |
-cp <classpath uri> | --classPath | Comma separated list of URI's representing the classpath. |
-tn <target namespace> | --targetNamespace | The target namespace for the WSDL. |
-tp <target namespace prefix> | --targetNamespacePrefix | The target namespace prefix for the WSDL. |
-sn <serviceName> | --serviceName | The service name to be put in the WSDL service section. |
-of <output file name> | --outputFilename | Name for the output file. |
-stn <schema target namespace> | --server-side | Target namespace for the schema. |
-stp <schema target namespace prefix> | --service-description | Target namespace prefix for the schema. |
-st <binding style> : | --databinding-method | Style to be used for the binding - rpc or document. |
-l <location> | --location | The value to be used in the address field. |
-u <use> | --use | The value of the 'use' attribute to be used in the binding, literal or encoded. |