Wsdl generate java code

WSDL to Java

wsdl2java — takes a WSDL document and generates fully annotated Java code from which to implement a service.

Synopsis

Usage : wsdl2java -fe|-frontend -db|-databinding -wv -p <[wsdl-namespace =]package-name>* -sn -b * -reserveClass * -catalog -d -compile -classdir -impl -server -client -clientjar -all -autoNameResolution -allowElementReferences|-aer -defaultValues -ant -nexclude * -exsh <(true, false)>-noTypes -dns <(true, false>-dex <(true, false)>-validate -keep -wsdlLocation -xjc* -asyncMethods<[=method1,method2. ]>* -bareMethods<[=method1,method2. ]>* -mimeMethods<[=method1,method2. ]>* -noAddressBinding -faultSerialVersionUID -exceptionSuper -mark-generated -suppress-generated-date -maxExtensionStackDepth -h|-?|-help -version|-v -verbose|-V -quiet|-q|-Q -wsdlList

Description

wsdl2java takes a WSDL document and generates fully annotated Java code from which to implement a service. The WSDL document must have a valid portType element, but it does not need to contain a binding element or a service element. Using the optional arguments you can customize the generated code. In addition, wsdl2java can generate an Ant based makefile to build your application.

Options

The options used to validate WSDL file are reviewed in the following table.

Displays the online help for this utility and exits.

Specifies the frontend. Default is JAXWS. Currently supports only JAXWS frontend and a «jaxws21» frontend to generate JAX-WS 2.1 compliant code.

Specifies the databinding. Default is jaxb. Currently supports jaxb, xmlbeans, sdo (sdo-static and sdo-dynamic), and jibx.

Specifies the wsdl version .Default is WSDL1.1. Currently suppports only WSDL1.1 version.

-p [ wsdl-namespace= ] PackageName

Specifies zero, or more, package names to use for the generated code. Optionally specifies the WSDL namespace to package name mapping.

The WSDL service name to use for the generated code.

Specifies JAXWS or JAXB binding files or XMLBeans context files. Use multiple -b flags to specify multiple entries.

Specify catalog file to map the imported wsdl/schema

Specifies the directory into which the generated code files are written.

Compiles generated Java files.

Specifies the directory into which the compiled class files are written.

Generates starting point code for a client mainline.

Generates the jar file which contains all the client classes and wsdl;the specified wsdlLocation won’t work when the -clientJar is defined.

Generates starting point code for a server mainline.

Generates starting point code for an implementation object.

Generates all starting point code: types, service proxy, service interface, server mainline, client mainline, implementation object, and an Ant build.xml file.

Specify to generate an Ant build.xml script.

Automatically resolve naming conflicts without requiring the use of binding customizations.

Specifies that default values are generated for the impl and client. You can also provide a custom default value provider. The default provider is RandomValueProvider

-nexclude schema-namespace [=java-packagename]

Ignore the specified WSDL schema namespace when generating code. This option may be specified multiple times. Also, optionally specifies the Java package name used by types described in the excluded namespace(s).

Enables or disables processing of implicit SOAP headers (i.e. SOAP headers defined in the wsdl:binding but not wsdl:portType section.) Processing the SOAP headers requires the SOAP binding jars available on the classpath which was not the default in CXF 2.4.x and older. You may need to add a dependency to cxf-rt-binding-soap for this flag to work. Default is false.

Enables or disables the loading of the default namespace package name mapping. Default is true and http://www.w3.org/2005/08/addressing=org.apache.cxf.ws.addressing namespace package mapping will be enabled.

Enables or disables the loading of the default excludes namespace mapping. Default is true.

Enables validating the WSDL before generating the code.

Specifies that the code generator will not overwrite any preexisting files. You will be responsible for resolving any resulting compilation issues.

Specifies the value of the @WebServiceClient annotation’s wsdlLocation property.

Specifies a comma separated list of arguments that are passed directly to the XJC processor when using the JAXB databinding. A list of available XJC plugins can be obtained using -xjc-X .

For compatibility with CXF 2.0, this flag directs the code generator to generate the older CXF proprietary WS-Addressing types instead of the JAX-WS 2.1 compliant WS-Addressing types.

Displays the version number for the tool.

Displays comments during the code generation process.

Suppresses comments during the code generation process.

superclass for fault beans generated from wsdl:fault elements (defaults to java.lang.Exception)

Used with -autoNameResolution, defines a class names for wsdl-to-java not to use when generating classes. Use this option multiple times for multiple classes.

(or -aer) If true, disregards the rule given in section 2.3.1.2(v) of the JAX-WS 2.2 specification disallowing element references when using wrapper-style mapping.

List of subsequently generated Java class methods to allow for client-side asynchronous calls, similar to enableAsyncMapping in a JAX-WS binding file.

List of subsequently generated Java class methods to have wrapper style (see below), similar to enableWrapperStyle in JAX-WS binding file.

List of subsequently generated Java class methods to enable mime:content mapping, similar to enableMIMEContent in JAX-WS binding file.

How to generate suid of fault exceptions. Use NONE, TIMESTAMP, FQCN, or a specific number. Default is NONE.

Adds the @Generated annotation to classes generated.

The path and name of the WSDL file to use in generating the code.

You must specify the absolute or relative path to the WSDL document as the last argument.

Examples

wsdl2java -p com.mycompany.greeting Greeting.wsdl

wsdl2java -client HelloWorld.wsdl

(See below for usage with Apache Ant and Maven.)

Using wsdl2java with Ant

The wsdl2java command can be wrapped inside an Ant target as shown below:

Make sure you set the «fork=true» attribute for the task as shown above. Also, remember to keep each word or flag within the command line options in its own element (e.g., do not use , but split them up into two elements as done here.)

Although we would recommend using Maven, see the antbuild sample in the CXF distribution for an example of using Ant to create a CXF project.

JAXWS Customization

The default JAX-WS frontend created by wsdl2java can be customized by using a customization binding file. For an example, see the async_binding.xml file in samples/jaxws_async – if specified when running wsdl2java, it will generate asynchronous methods in the SEI.

Q: What if I want to change the generated SEI name?

A: We don’t have a command-line option to do this, but you can have a binding file like the following snippet to achieve this goal

Q: How do I pass the binding file to wsdl2java?

A: If you are using wsdl2java via command line tool:

wsdl2java HelloWorld.wsdl -b my_binding.xml

For Ant, follow the example above on how to add «-b» and «my_binding.xml» as arg elements.

Q: How to map xsd:dateTime to java.util.Date?
Well, people don’t like the XMLGregorianCalendar which is the default mapping from the xsd:dateTime (xsd:time and xsd:date as well),
We can use the jaxws customization to change the default mapping, here are some sample binding files
If you have schema inside the wsdl, here is the binding file you can use:

This requires an additional dependency:

 org.apache.cxf.xjc-utils cxf-xjc-runtime  

If you want to use java.util.Calendar, just change the org.apache.cxf.xjc.runtime.DataTypeAdapter to javax.xml.bind.DatatypeConverter, and change the name value to «java.util.Calendar»

If your schema is out of wsdl, here is an example you can try:

Q: How can I switch my generated web service method calls from wrapper style to non wrapper-style (or vice-versa)?

A: Create an external binding file and set the value of to true or false as desired:

Alternatively you can embed this instruction within the WSDL file directly, as the immediate child of the wsdl:portType:

  false . other binding settings if needed . . 

Note: The meaning of «wrapper-style» and «non-wrapper style» as defined in the JAX-WS 2.1 specification can be counterintuitive. Wrapper-style indicates that each data element within the request message gets its own Java parameter, while non-wrapper style means that a single Java object containing all the data elements serves as the lone parameter to the web service method call. (See Figure 2.2 of the specification for an example.) Also, note the wrapper style is not always available, the WSDL criteria specified in Section 2.3.1.2 («Wrapper Style») of the specification must be met or only non-wrapper style will be generated.

Q: What else can I change with the JAXWS customization binding file?

A: You can find the full list of customization items in Chapter 8 of the JAX-WS Specification.

Источник

Generate Java Code from WSDL dialog

This functionality is available if you have installed and enabled the Jakarta EE: Web Services (JAX-WS) plugin.

The dialog opens after you create a Java module and enable Web services client development in it. To access the dialog at any time during development, select the desired client module in the Project view and choose Tools | XML WebServices and WSDL | Generate Java Code From WSDL from the main menu.

Use the Generate Java Code From WSDL dialog to generate the client-side XML-Java bindings based on the desired WSDL descriptor of the target Web service. Technically, IntelliJ IDEA generates Java code from WSDL using third party libraries. The command that control this process uses data that you specify in the Generate Java Code From WSDL dialog.

Specify the location of the target Web service WSDL descriptor.

Specify the credentials for accessing the WSDL URL address. The fields are mandatory if the WSDL location requires authentication.

Specify the module source directory to place the generated files in.

Specify the package for the compiled Java classes.

Specify whether you want to generate Java code only for the client side or for the server side as well.

Specify the default type mapping registry for mapping an XML qualified name to a Java class, using a specified Deserializer. The available options are:

Generate Java code for the extension points contained in the WSDL file.

Generate an additional JUnit test case class for testing purposes.

Generate Classes for Schema Arrays

Specify whether to generate classes for schema arrays or use Java arrays.

Generate Unreferenced Elements

Generate Java code for unreferenced (declared in the schema but not used) elements as well.

Support Wrapped Document/Literal Style

Configure processing of «wrapped» document/literal, which is a document literal variation that wraps parameters as children of the root element.

By default, this is enabled, and a set of conditions defines whether top-level elements are «unwrapped» and each component of the element should be treated as an argument of the operation. The following conditions apply to «unwrapped» elements:

• An input message consists of single part.
• This single part is an element.
• The element has the same name as the operation.
• The element’s complex type has no attributes.

If disabled, there will be no special treatment for «wrapped» document/literal style operations.

View the information in this read-only field to track and improve discrepancies when configuring the code generation procedure.

Источник