6.6.0.15.1: Generating EJB deployment code from the command line

Before you can successfully run your enterprise beans on either a test or production server, you need to generate deployment code for the enterprise beans. The Deployment Tool for Enterprise JavaBeans (referred to in the remainder of this topic as simply the EJB Deploy Tool) provides a command-line interface that you can use to generate enterprise bean deployment code. The tool employs a command-line environment that allows you to run a build process overnight and have the deployment tool automatically invoked to generate your deployment code in batch mode.

The EJB Deploy Tool is invoked from the command line using the ejbdeploy command, which accepts an input EJB JAR file that contains one or more enterprise beans. It then generates an output deployed JAR file that contains deployment  code in the form of .class files.

Specifically, when you run the ejbdeploy command, the following activities occur:

  • Code is imported from the input JAR file
  • Deployment code is generated
  • RMIC is run
  • The deployment code is compiled
  • Code is exported to the output JAR file

These activities are discussed further in some of the descriptions for the options that can be specified with the ejbdeploy command.

The EJB Deploy Tool supports meet-in-the-middle mapping, EJB single and multiple table inheritance, and associations that have been defined in VisualAge for Java. It also supports the use of converters, which translate a database representation to a Java object type, and composers, which are used to map a single complex bean field to multiple database columns.

For information about migrating entity beans from WebSphere Application Server Version 3.5, see the section below entitled "Migrating CMP entity beans from WebSphere Application Server, Version 3.5". For information about generating deployment code for VisualAge for Java enterprise beans and running them in WebSphere Application Server, see the section below entitled "Deploying and running VisualAge for Java enterprise beans in WebSphere Application Server".

Syntax

ejbdeploy input_JAR_name working_directory output_JAR_name [-codegen] [-cp classpath] [-dbname name] [-dbschema name] [-dbvendor name] [-ignoreErrors] [-keep] [-noinform] [-no validate] [-nowarn] [-quiet] [-rmic "options"] [-trace] [-35]

Command arguments

ejbdeploy
The command to generate deployment code. If run without any arguments, the ejbdeploy command displays a list of arguments that can be run with the command.
input_JAR_name
The fully qualified name of the input JAR file that contains the enterprise beans for which you want to generate deployment code; for example, c:\ejb\inputJARs\myEJBs.jar. (This argument is required.) If your input JAR file contains CMP beans, the ejbdeploy command automatically creates the schemas and mappings for the CMP beans. It is important to note that the ejbdeploy command no longer uses what is specified on the system class path. Instead, the dependent classes need to be contained in a JAR file and included in the command processing using the -cp option. You must ensure that the .class files of each enterprise bean's home and remote classes are packaged in the input JAR file. (Note that the best way to specify dependent JAR files is through the Java extension mechanism and by listing the required JAR files in the manifest file of the input JAR file. The EJB Deploy Tool will respect these extensions and you won't need to specify them using a command-line option.)
working_directory
The name of the directory where temporary files are stored that are required for code generation. (This argument is required.) If the working directory that you specify already exists prior to running the ejbdeploy command, the temporary files are generated into the working directory and are not removed. However, if the working directory does not already exist prior to running the command, the directory is created and the temporary files are generated into it, but the directory and all of the temporary files are later automatically removed when the deployment code generation is complete. (If you do not want the working directory to be removed when the deployment code generation is complete, use the -keep option.)
output_JAR_name
The fully qualified name of the output JAR file that is created by the ejbdeploy command and that contains the generated classes required for deployment; for example: c:\ejb\outputJARs\myEJBs.jar. 
(This argument is required.) The directories specified in the fully-qualified name must already exist before you run the ejbdeploy command. (Note that when you specify a name for the output JAR file and then run the ejbdeploy command, any existing output JAR file of the same name will be overwritten without warning.)
-codegen
Restricts the ejbdeploy command to just (a) importing code from the input JAR file (b) generating the deployment code, and (c) exporting code to the output JAR file. (If you do not specify the -codegen option, the ejbdeploy command performs the same operations as those performed using the -codegen option, but it will additionally compile the generated deployment code and run RMIC.)
-cp classpath
If you intend to run the ejbdeploy command against JAR files that have dependencies on other JAR files, you can use the -cp option to specify the classpath of the other JAR files. Using the -cp option, you can specify multiple JAR files as arguments. However, the JAR file names must be fully qualified, separated by semicolons, and enclosed in double quotation marks. For example:
-cp "path\myJar1.jar; path\myJar2.jar; path\myJar3.jar"
-dbname name
The name of the database you want to create. If the name of the database contains any spaces, the entire name must be enclosed in double quotes. For example:
-dbname "my database"
-dbschema name
The name of the schema you want to create. If the name of the schema contains any spaces, the entire name must be enclosed in double quotes. For example:
-dbschema "my schema"
(Note that this option is only used when creating a database definition in the top-down mode of operation. The database information is then saved in the schema document in the JAR file, meaning that the options do not need to be re-specified. It also means that when a JAR is generated by VisualAge for Java or WebSphere Studio Application Developer, the correct database must be defined at that point because it cannot be changed later.)
-dbvendor name
The name of the database vendor, which is used to determine database column types, mapping information, Table.ddl, and other information. The valid database vendor names are:
SQL92 (Generic SQL 92)                          
SQL99 (Generic SQL 99) 
DB2UDBWIN_V61 (DB2 for Windows, V6.1)
DB2UDBWIN_V72 (DB2 for Windows, V7.2)
DB2UDBOS390_V6 (DB2 for OS/390, V6)
DB2UDBAS400_V4R5 (DB2 for OS/400, V4 R5)
ORACLE_V8 (Oracle, V8.0)
INFORMIX_V92 (Informix Dynamic Server.2000, V9.2) 
SYBASE_V1192 (Sybase Adaptive Server Enterprise, V11.9.2)
MSSQLSERVER_V7 (MS SQL Server, V7)
MYSQL_V323 (MySQL, V3.23)
-ignoreErrors
Specifies that processing should continue even if compilation or validation errors are detected.
-keep
Retains the working directory after the ejbdeploy command has run.
-noinform
Suppresses informational messages.
-novalidate
Prevents the validators from running. (When you generate deployed code in batch mode from the command line, all of the installed validators are automatically run on the specified JAR file unless you specify this -novalidate option, which prevents all validators from running.) Note that the -nowarn option is generally a better options to use. It will hide any warnings but still display errors that may prevent the bean from deploying or running on the server.
-nowarn
Suppresses warning and informational messages.
-quiet
Suppresses status messages (but does not suppress error messages).
-rmic "options"
Enables you to pass RMIC options to RMIC. The options, which are described in Sun's RMI Tools documentation, must be separated by a space and enclosed in double quotation marks. For example:
-rmic "-nowarn -verbose"
-trace
Generates trace information.
-35
For CMP entity beans, the EJB Deploy Tool looks in the JAR file for an existing schema and map to use when generating deployment code. If no existing schema and map are found, a schema and map are created using improved top-down mapping rules. If you want to use the same top-down mapping rules for CMP entity beans that are used in the EJB Deploy Tool provided with WebSphere Application Server, Version 3.5, then specify the -35 option. This may be desirable in some situations. However, if you do not specify the -35 option, a form of top-down mapping is used that is an improvement over what has previously been available. (In the top-down mapping  approach, you already have existing enterprise beans and their design determines the database design. You generate a schema and map and the generated schema contains one table for each entity bean with container-managed persistence. In these tables, each column corresponds to a CMP field of the enterprise bean, and the generated mapping maps the field to the column.)

Migrating CMP entity beans from WebSphere Application Server, Version 3.5

To migrate CMP entity beans from WebSphere Application Server, Version 3.5, to WebSphere Application Server, Version 4.0, the existing EJB applications should be migrated over and redeployed using the -35 option of the EJB Deploy Tool so that the existing (older) table rules are kept. To migrate the beans manually, the EJB JAR requiring migration must be invoked through the command line and the -35 option should be used. Without this option, the database table will follow a new set of rules which is more aligned with the defaults for VisualAge for Java.

Deploying and running VisualAge for Java enterprise beans in WebSphere Application Server

To run an enterprise bean created in VisualAge for Java on WebSphere Application Server Version 4.0, you must first generate deployment code for it using the EJB Deploy Tool. 

(Note that you cannot use the EJB => Generate deployed code menu item in VisualAge for Java, because it is designed to support the embedded VisualAge for Java WebSphere Test Environment that is based on WebSphere Application Server, Version 3.5. Also, you cannot use the EJB Deploy Tool that is shipped with the June 2001 release of WebSphere Application Server, Version 4.0, because it does not support all of the function that is available in VisualAge for Java.)

To deploy and run a VisualAge for Java enterprise bean on WebSphere Application Server, Version 4.0:

  1. In the VisualAge for Java EJB Development Environment, select the EJB => Export => Export EJB 1.1 JAR menu item. This calls the Export Tool for Enterprise Java Beans 1.1, which enables you to create a JAR file that can be deployed to WebSphere Application Server. (If you don't use the Export Tool for Enterprise JavaBeans 1.1, no mappings, inheritance, or associations will be exported.)
  2. Open a command window and change to the directory where you installed the EJB Deploy Tool.
  3. Run the ejbdeploy command and use the JAR that you created in VisualAge for Java as your input JAR file. This will create an output deployed JAR file.
  4. Install the deployed JAR file into WebSphere Application Server, Version 4.0. Depending on your edition of WebSphere Application Server, this can be accomplished using either the SEAppInstall tool or the WebSphere Application Assembly Tool. If your edition of WebSphere Application Server includes the SEAppInstall tool and you want to use the SEAppInstall tool from the command line, ensure that you specify the "-ejbdeploy false" option, so that the earlier version of the EJB Deploy Tool that shipped with WebSphere Application Server Version 4.0 is not invoked.

Note that for CMP entity beans, a data definition language (DDL) that can be used to create corresponding database tables for a JAR file is contained within the META-INF directory and entitled Table.ddl. (In VisualAge for Java, Version 3.5, this information used to be directed into the generated persister. The table creation is now a task left up to the user, but it is made more convenient by the Table.ddl file.)

Go to previous article: Log Analyzer Preferences notebook -- Analyzer output Go to next article: Meet-in-the-middle mapping support

 

 
Go to previous article: Log Analyzer Preferences notebook -- Analyzer output Go to next article: Meet-in-the-middle mapping support