8.1.1 Importing the J2EE applications that are in archive format

(1) Precautions related to runtime information

The term runtime information references to the Cosminexus J2EE server-specific information. The runtime information includes the following information.

Table 8‒1: List of runtime information

Items	Information
Status of J2EE application	Information about start or stop status
Various settings of J2EE applications	Runtime properties of Enterprise Beans Mapping of each reference and J2EE resource Mapping of CMP field database
Auto-generated implementation class	EJB home object EJB object
stub class, tie class of the remote interface	EJB home object EJB object

The following are the precautions to be taken when importing the EAR files that include the runtime information:

• The status of a J2EE application (when the J2EE application was exported) is restored. Consequently, if a running J2EE application is imported, the execution of the J2EE application starts immediately.

• The various settings of the J2EE applications are restored. If you create a J2EE resource adapter, JDBC data source, or JavaMail configuration with the same name as that of the exported J2EE server on the J2EE server to be imported, then the reference is resolved when importing the J2EE application. Therefore, when importing a running J2EE application, create a J2EE resource adapter, JDBC data source, or JavaMail configuration beforehand by using the same name as that of the J2EE server that was exported. Furthermore, import the J2EE application when the J2EE resource adapter is running.

• The auto-generated implementation class, remote interface stub class, and remote interface tie class included in an EAR file with runtime information are re-used; however, these classes are re-created when you import an EAR file that was exported with an earlier version.

• Ensure that the execution environment information file is not changed.

To Page Top

(2) Precautions related to DDs of EARs

You cannot import an EAR containing DDs not conforming to Java EE specifications.

If the DD version is old, the version is changed to as follows.

Table 8‒2: Changing DD version

DD	Version before importing	Version after importing
application.xml	1.2	1.4
	1.3
ejb-jar.xml	1.1	2.0
web.xml	2.2	2.3

To Page Top

(3) Other precautions

• Do not include files with the following names when the files to be imported are not the J2EE applications that are exported from aJ2EE server:

  • hitachi-runtime.jar

  • rar.properties

  • fileinfo.properties

  • META-INF/hitachi-ra.xml

• When a J2EE application is started, a name that corresponds to J2EE-APP-name in the JNDI name space of the EJB home object (HITACHI_EJB/SERVERS/server-name/EJB/J2EE-APP-name/Enterprise-Bean-name) is automatically allocated. For details on the JNDI name space, see 2.3 Binding and lookup of objects to the JNDI name space in the uCosminexus Application Server Common Container Functionality Guide.

• The EJB-JAR file name in an EAR file is used as a directory name in the working directory. If there is a class that implements java.rmi.Remote (for example, the home interface) in the EJB-JAR file, then based on the definition in the usrconf.properties file, a stub is generated in the working directory when deploying or starting the application. In the case of default settings, a stub is generated for the <remote> and <home> interfaces coded in ejb-jar.xml. If you specify app in the ejbserver.deploy.stub.generation.scope key of the usrconf.properties file, the stubs will be generated for all the interfaces that implement the remote interface included in the EJB-JAR file.

  Considering the above points, specify an EJB-JAR file name and the package name and the class name of the class that implements java.rmi.Remote so that the path length of the working directory is within the limit specified for the platform.

  For details on estimating the path length of the working directory, see C.1 Work directory of the J2EE server in the uCosminexus Application Server System Setup and Operation Guide.

• The WAR file name in an EAR file is used as a directory name in the working directory. The files in a WAR file are deployed in the working directory. If a WAR file contains a class that implements java.rmi.Remote (for example, the home interface), then based on the definition in the usrconf.properties file, a stub is generated in the working directory when deploying or starting an application.

  If you specify app in an ejbserver.deploy.stub.generation.scope key of the usrconf.properties file, the stubs will be generated for all the interfaces that implement the remote interface of the WAR file.

  Considering the above points, specify the WAR file name, the package name and class name of the WAR file, and the package name and class name of the class that implements java.rmi.Remote, so that the path length of the working directory does not reach the limit specified for the platform.

• The library JAR file name in an EAR file is used as a directory name in the working directory. Specify the JAR file name so that the path length of the working directory does not reach the limit specified for the platform.

• You cannot import the files when the display names of EJB-JAR files and WAR files in EAR files are the same. When a display name is a blank character or is not specified, a character string where the file name is changed is specified. You cannot import the file even when this value is duplicated.

• If an error occurs in the runtime information of a J2EE application that contains imported runtime information, importing of the 2EE application fails. At this time, the J2EE application is deleted without being started. To avoid the deletion of the J2EE application, specify the -nodelete option of the cjimportapp command to import the J2EE application. In such a case, the J2EE application can be imported without being deleted but since the application does not start automatically, eliminate the errors as and when required and then start the J2EE application.

• The rules to convert the display name and the directory name when the applications to be imported include application.xml are as follows:

  • The value of the <display-name> tag in application.xml becomes the display name.

  • If the <display-name> tag does not have a value, a string converting the EAR file name specified in the -f option is considered as the display name.

    Note that if the file name contains characters other than general-purpose characters and numbers, the characters are substituted by underscores (_).

    If the characters to be substituted are continuous, the characters are combined into one underscore (_).

  • The name excluding the extension from the path name described in the <module> tag in application.xml becomes the same name as the EJB-JAR directory name or WAR directory name.

• The rules to convert the display name and the directory name when the applications to be imported exclude application.xml are as follows:

  • The converted string excluding the extension from the file name specified in the -f option becomes the display name.

    Note that the characters other than one-byte alphanumeric characters (0 to 9, A to Z, and a to z) and underscores (_) are substituted by underscores (_).

  • For file names that begin with a period (.), the period (.) is not removed and the converted character string becomes the display name.

  • The EJB-JAR directory name will end with _jar and the WAR directory name will end with _war.

To Page Top