Code Generation Details
Description Field
The name of the Spring plug-in project to contain the implementation.
Default: com.sample.spring. Project
The name of the source folder in the plug-in project.
Default: src. Source Folder
The path to the Spring Bean configuration file relative to the Spring plug-in project.
Default: config-compositeName-componentName/compositeName_componentName_beans.xml. Bean Configuration
File
XML Data Binding Classes
If the component does not have any services or references, this screen does not display.
Description Field
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 Type
changed since the JAR file was generated, the Overwrite Existing JAR checkbox will be checked.
Default: XMLBeans.
Generating implementations for two or more components in the same Java plug-in project using different binding types is not supported.
A list of WSDL and schema files for which XML data binding classes will be generated.
Contracts
The type of JAR file being generated: Beans or Interface.
JAR Type
The path to the source file containing the selected contract.
Source File
The path to the generated JAR file.
Default: When generating a component implementation:
JAR File
• 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.
Spring Component Implementations | 35
Description Field
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.
Use this JAR for All Data Bindings
Invokes a dialog where you can set the folder to contain generated JAR files:
Set JAR Folder
• 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.
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.
The status of the JAR file containing the classes generated for the selected contract:
JAR Status
• 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.
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.
Overwrite Existing JAR
Advanced
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 Export Data Binding
Packages
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.
36 | Spring Component Implementations
Description Field
The name of the generated bean.
Default: serviceNameBean. Bean ID
The name of the package of the implementation class.
Package
The name of the class of the implementation.
Default: serviceNameImpl. If no service is defined on the component, the default class name is componentName.
Class
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.
Use Default Location for Superclass
The name of the package of the abstract superclass of the implementation class.
Default: com.sample.projectName. Superclass Package
The name of the abstract superclass of the implementation class.
Default: AbstractComponentName. Superclass Class
Related Topics
Generating a Spring Component Implementation on page 31 Default XML to Java Mapping on page 75
Generating a Spring Component Implementation on page 31 Default XML to Java Mapping on page 75
Spring Component Implementations | 37