When nothing is pre-generated, the WaspPackager tool will generate the deployment descriptor and WSDL files for specified services. You can define any number of services on the command line. Since everything is generated with default values, this is one of the fastest methods to create a deployment package file.

	Note
	Once Web service class sources are available in the classpath, they are observed and parameter names are read from them and fed into WSDL.

The command-line options are explained in Table 24, “Package Creation Switches”, Table 25, “Options for Including Classes in the Package” and Table 27, “Options for Adding New Services to the Package”

The command in Example 194 packages the HelloService class when nothing has been pregenerated.

WaspPackager --package MyPackage --output mypack.jar --service-name HelloService
--uri /HelloService --class demo.basic.hello.server.HelloService 
--classpath ../demo/basic/hello/build/server/classes

You may want to use your own WSDL as a definition of the service. In this case, simply specify this fact together with the service definition. Note that parameter names will not automatically be read from Web service class sources and fed into WSDL when you use your own WSDL.

The command-line options are explained in Table 24, “Package Creation Switches”, Table 25, “Options for Including Classes in the Package” and Table 27, “Options for Adding New Services to the Package”

The command line in Example 195 places HelloService into a package using a WSDL file provided by the user (HelloService.wsdl).

WaspPackager --package MyPackage --output mypack.jar
--service-name HelloService --uri /HelloService --class demo.basic.hello.server.HelloService
--wsdl-file HelloService.wsdl --wsdl-service HelloService 
--classpath ../demo/basic/hello/build/server/classes

	Note
	If your WSDL contains only one Service element, it is retrieved by default, so you need not specify it on the command line.

You can provide WaspPackager with the location of a pregenerated deployment descriptor (dd) file with the command:

The full list of options for adding a pregenerated deployment descriptor is given in Table 29, “Options for Adding Your Own Deployment Descriptor”.

If a service is defined on the command line, the dd is updated accordingly.

The command in Example 196 includes the HelloService into a package using an existing deployment descriptor.

WaspPackager --package MyPackage --output mypack.jar
--dd mydesc.xml --classpath classes

The command in Example 197 packages the same service when the service definition is not included in the dd file.

WaspPackager --package MyPackage --output mypack.jar
--service-name HelloService --uri /HelloService --class demo.HelloService --classpath classes
--dd mydesc.xml

WSDL files can be generated for services that already have deployment descriptors (dd). The dd is updated accordingly after generating the WSDL. The options are almost the same as for generating a package with a pregenerated dd (please see Pregenerated Deployment Descriptor), except for one additional switch (-g).

The full list of options for adding a pregenerated deployment descriptor is given in Table 29, “Options for Adding Your Own Deployment Descriptor”.

The command in Example 198 generates a WSDL file based on a deployment descriptor called mydesc.

WaspPackager --package MyPackage --output mypack.jar
--dd mydesc.xml --generate-wsdl-dd --classpath classes

When using your own WSDL and deployment descriptor files for packaging, be sure that the WSDL files are specified after the --dd option.

The options for adding a pregenerated deployment descriptor and WSDL file are given in Table 24, “Package Creation Switches” and Table 29, “Options for Adding Your Own Deployment Descriptor”.

The command in Example 199 includes a service into the package MyPackage with a pregenerated deployment descriptor called mydesc.xml and a pregenerated WSDL file called mypack.wsdl.

WaspPackager --package MyPackage --output mypack.jar
--dd mydesc.xml --wsdl-file mypack.wsdl

You can specify all the important parameters of a deployment package using the options in Table 30, “Options for Defining Package Parameters”.

The command in Example 200 creates the package MyPackage with the HelloService, dependent on the class http://my.org:Debugger:

WaspPackager --package MyPackage --output mypack.jar
--service-name HelloService --class demo.HelloService --uri /HelloService
--classpath classes --depends http://my.org:Debugger --min-version 1.2.1

Some Web services require special files and Java libraries to be packed with them. The relevant options are listed in Table 28, “Options for Adding Additional Files and Directories into Package”.

A file added using -a file can be accessed using getResource(java.lang.String) in org.systinet.wasp.webservice.ServiceInstance or getResourceAsStream(java.lang.String) in org.systinet.wasp.webservice.ServiceInstance.

All WSDL files generated by WaspPackager contain, by default, document binding and literal encoding styles. You can affect this behavior by using the --soap-binding-style and --soap-encoding-style parameters, described in Table 27, “Options for Adding New Services to the Package”.

The WSDL file generated by the command in Example 201 contains rpc binding and encoded encoding styles.

WaspPackager --package MyPackage --output mypack.jar
--service-name HelloService --class demo.HelloService --uri /HelloService
--sbs rpc --ses encoded --classpath classes

Some Web services require special classes to be situated on the client side (header processors, serializers, etc.). WaspPackager can be used to create client packages which contain these classes. These packages should be put in the client classpath. The client package has a slightly different structure than the server package, as described in Client Package.

The command in Example 202 creates a client package with a pregenerated deployment descriptor.

WaspPackager --client --package MyClientPackage --output mypack.jar
--dd mydesc.xml --classpath classes

Services are deployed to server_url/context/{tns}service_path. Usually the context is blank, so for example the HelloService may be deployed to http://localhost:6060/{http:my.org}HelloService. However, you can specify a context with the --context option. The command line in Example 206 will deploy the HelloService to http://localhost:6060/helloContext/{http:my.org}HelloService.

Deploy --context helloContext ../demo/basic/hello/server/classes/hello.jar

For more information on contexts, please see Contexts.

WSDL files generated by Deploy contain a SOAP binding and encoding style. The default style is chosen during installation. You can override this default by using the following parameters:

	Note
	The 'wrapped/literal' style is WS-I compliant but may cause backward compatibility issues with older clients. See WS-I Compliance for details.

The WSDL file generated by the command in Example 207 contains rpc binding and encoded encoding styles.

Deploy --class demo.basic.hello.server.HelloService --url /HelloService/
      --sbs rpc --ses encoded

You can retrieve a complete list of deployed packages from the server with either Deploy or Undeploy:

Deploy --list

Undeploy --list

By default, this command lists the packages deployed to http://localhost:6060. To list the packages deployed to another URL, use the --target URL option.

There exist a few other optional switches, mostly for providing information to the user. There is also a switch for disabling the validation of package deployment descriptors against the latest XML Schema.