Generate Java Component Implementation Reference

When you generate a Java implementation you specify the project location, package, and names of the implementation classes and the type of the XML data binding classes and location of the JAR file containing the classes.

Implementation Classes

Field Description
Project The name of the plug-in project to contain the implementation.

Default: com.sample.soaprojectname.

Source Folder The name of the source folder in the plug-in project.

Default: src.

Package The name of the package of the implementation class.

Default: com.sample.soaprojectname.

Class The name of the implementation class.

Default: ComponentName, where ComponentName is the name of the component.

Overwrite Concrete Class Indicate whether to overwrite the implementation class if it already exists.

Default: Unchecked.

Use Default Location for Superclass Indicate whether to generate the superclass of the implementation class in the same package as the implementation class and name the class AbstractComponentName. When unchecked, the Superclass Package and Superclass fields are enabled.

Default: Checked.

Superclass Package The name of the package of the superclass of the implementation class.

Default: com.sample.soaprojectname.

Superclass The name of the superclass of the implementation class.

Default: AbstractComponentName.

XML Data Binding Classes

Note: If the component does not have any services or references, this screen does not display.
Field Description
Type The type of the data binding being generated: XMLBeans or JAXB.

If a JAR file already exists for the contract selected in the Contracts list, and you choose a binding type different than the one that exists in the JAR file or the contract has changed since the JAR file was generated, the Overwrite Existing JAR checkbox will be checked.

Default: XMLBeans.

Note: Generating implementations for two or more components in the same Java plug-in project using different binding types is not supported.
Contracts A list of WSDL and schema files for which XML data binding classes will be generated.
JAR Type The type of JAR file being generated: Beans or Interface.
Source File The path to the source file containing the selected contract.
JAR File The path to the generated JAR file.

Default: When generating a component implementation:

  • Beans - projectName/libs/contractFileName.wsdl.jar
  • Interface - projectName/libs/contractFileName.wsdl_interface.jar

where contractFileName is the name of the file containing the contract selected in the Contracts list and projectName is the name of the project containing the component implementation.

When generating from a contract file:
  • Beans - projectName.libs/libs/contractFileName.wsdl.jar
  • Interface - projectName.libs/libs/contractFileName.wsdl_interface.jar

where contractFileName is the name of the file containing the contract selected in the Contracts list and projectName is the name of the project containing the contract file.

Use this JAR for All Data Bindings Indicate that all data binding classes should be generated into the JAR file specified in the JAR File field. You must generate all data binding classes into a single JAR file whenever there are cyclical references between schema files.
Set JAR Folder Invokes a dialog where you can set the folder to contain generated JAR files:
  • All Generated JARs - All JAR files will be generated in the same folder as the destination of the currently selected JAR.
  • New Generated JARs - Only newly generated JAR files will be generated in the same folder as the destination of the currently selected JAR file.
Note: Setting the JAR folder affects only the JAR files generated by the wizard. It has no effect outside the wizard nor on subsequent wizard runs.

Default: All Generated JARs.

JAR Status The status of the JAR file containing the classes generated for the selected contract:
  • JAR is non-existent and will be generated. - The JAR file does not exist.
  • Different binding type. JAR must be overwritten. - The value of the Type field is different than the type of the data binding classes in the JAR file.
  • JAR exists and will be overwritten. - The JAR file exists and the Overwrite Existing JAR checkbox is checked.
  • JAR exists and will be preserved. - The JAR file exists and the Overwrite Existing JAR checkbox is unchecked.
  • JAR is outdated and will be overwritten. - The selected contract has changed since the JAR file was generated and the Overwrite Existing JAR checkbox is checked, so the JAR file will be generated.
  • JAR is outdated and will be preserved. - The selected contract has changed since the JAR file was generated and the Overwrite Existing JAR checkbox is unchecked, so the JAR file will not be generated.
Overwrite Existing JAR Enabled only when the JAR file exists. When checked, the JAR file will be regenerated. When unchecked, the existing file will be reused and will not be modified.
Advanced
Export Data Binding Packages Indicate that all packages of classes generated into the same plug-in as the component implementation should be exported in the component's implementation plug-in manifest using the Export-Package directive. This allows you to reuse data binding JAR files generated into the same plug-in as the component implementation. However, this is not the recommended approach for data binding library sharing. Instead, you should generate data binding JAR files into a separate plug-in project.

Default: Unchecked.

Use Configuration File Indicate that the specified data binding configuration file should be used when generating JAR files. When you check the checkbox, the text field is enabled.

Default: Unchecked.