The ejbdeploy command

The ejbdeploy command

+
Search Tips | Advanced Search

Overvie

If your input JAR or EAR file contains CMP beans, the EJB deployment tool looks 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 top-down mapping rules.

In the top-down mapping approach, you already have existing enterprise beans and their design determines the database design. The generated schema contains one table for each CMP entity bean. In these tables, each column corresponds to a CMP field of the enterprise bean, and the generated mapping maps the field to the column.

Syntax

Use the following command and the optional parameters, when the schema and map are provided in the input EAR file:
ejbdeploy input_JAR_name 
          working_directory 
          output_JAR_name
          [ -cp classpath ] 
          [ -codegen ] 
          [ -debug ] 
          [ -keep ]
          [ -ignoreErrors ] 
          [ -quiet ] 
          [ -nowarn ] 
          [ -noinform ]
          [ -rmic "options" ] 
          [ -target name ]
          [ -trace ] 
          [ -sqlj ]
Use the following command and the optional parameters, when the schema and map are not available in the input EAR file, and a top-down mapping approach is needed:
ejbdeploy input_JAR_name working_directory output_JAR_name 
          [ -cp classpath ] 
          [ -codegen ] 
          [ -dbname name ]
          [ -dbschema name ] 
          [ -dbvendor name ]
          [ -debug ] 
          [ -keep ] 
          [ -ignoreErrors ] 
          [ -quiet ]
          [ -nowarn ] 
          [ -noinform ] 
          [ -rmic "options" ]
          [ -35 ] 
          [ -40 ] 
          [ -target name ] 
          [ -trace ]
          [ -sqlj ]
          [ -OCCColumn ]
Note:
The -dbschema, -dbname, -dbvendor, -OCCColumn, -35, and -40 options are 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 or EAR file, which means that the options do not need to be specified again. It also means that when a JAR or EAR is generated, the correct database must be defined at that point because it cannot be changed later.
By default, a data definition language (DDL) file is created with the backend set to DB2 when you run the ejbdeploy command. If you want to set a different database backend, use the -dbname, -dbschema, and -dbvendor options to specify your choice. However, you can have only one backend defined. If the JAR file already contains a DB2 backend, and you specify -dbvendor ORACLE on the command line, rather than getting a second backend, the dbvendor specification is ignored.

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 or input_EAR_name

The fully qualified name of the input JAR or EAR 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.)
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 or 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 or EAR file.

You should not include source files in the input JAR or EAR file. If there are source files in the input JAR or EAR file, the EJBDeploy tools runs a rebuild before generating the deployment code. Recommendation: Either remove the source files, or include all dependent classes and resource files on the class path. Otherwise, this might cause problems during rebuild of your application on the server.

working_directory

The name of the directory where temporary files that are required for code generation are stored. (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 (as an Eclipse workspace). However, if the working directory does not already exist prior to running the command, the directory is created and the Eclipse workspace is generated into it. In both cases, the workspace and all of its files are automatically removed when the deployment code generation is complete unless you specify the -keep option. (Retaining the workspace is useful for problem determination.)

output_JAR_name or output_EAR_name

The fully qualified name of the output JAR or EAR 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 or EAR file and then run the ejbdeploy command, any existing output JAR or EAR file of the same name will be overwritten without warning.)

-cp classpath

If you intend to run the ejbdeploy command against JAR or EAR files that have dependencies on other zipped or JAR files, you can use the -cp option to specify the class path of the other JAR or zipped files. Using the -cp option, you can specify multiple zipped and JAR files as arguments. However, the zipped and 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"
Tip: You need to specify the location of the SQLJ translator classes, sqlj.zip. The default path for this file is x:\java, where x is the installation directory of DB2, for example, d:\sqllib\java\sqlj.zip on Windows.

-codegen

Restricts the ejbdeploy command to just (a) importing code from the input JAR or EAR file (b) generating the deployment code, and (c) exporting code to the output JAR or EAR file. It will not compile the generated deployment code or run RMIC. Since Java source code is not usually exported in the output EAR or JAR, this is the only way to save the generated code.

-bindear "options"

Enables you to populate an EAR file with bindings. This argument applies only to EAR files. You can also use this command without specifying any options. The options must be separated by a space and enclosed in double quotation marks. For example: -bindear "xx yy zz" For more information on these options, see the WebSphere Application Server documentation.

-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"

-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:
DB2UDB_V81 (DB2 Universal database V8.1 for Windows and UNIX)
DB2UDB_V82 (DB2 Universal database V8.2 for Windows and UNIX)
DB2UDBOS390_V7 DB2 Universal Database for z/OS and OS/390, V7)
DB2UDBOS390_V8 (DB2 Universal Database for z/OS and OS/390, V8)
DB2UDBISERIES (DB2 for iSeries)
DB2UDBISERIES_V52 (DB2 for iSeries, V5R2)
DB2UDBISERIES_V53 (DB2 for iSeries, V5R3)
ORACLE_V8 (Oracle, V8.0)
ORACLE_V9I (Oracle, V9i)
ORACLE_V10G (Oracle, V10g)
INFORMIX_V73 (Informix Dynamic Server.2000, V7.3)
INFORMIX_V93 (Informix Dynamic Server.2000, V9.3)
INFORMIX_V94 (Informix Dynamic Server.2000, V9.4)
SYBASE_V1200 (Sybase Adaptive Server Enterprise, V12.0)
SYBASE_V1250 (Sybase Adaptive Server Enterprise, V12.5)
MSSQLSERVER_2000 (Microsoft SQL Server 2000)
MSSQLSERVER_V7 (Microsoft SQL Server, V7.0)
CLOUDSCAPE_V5 (Cloudscape, V5.1)

Note:
The default is DB2UDB_V81(DB2 for Windows, V8.1 and UNIX)
If -sqlj is specified, it supports DB2UDB_V82 (DB2 for Windows, V8.2 and UNIX), DB2UDB_V81 (DB2 for Windows, V8.1 and UNIX), DB2UDBOS390_V8 (DB2 for OS/390, V8) and DB2UDBOS390_V7(DB2 for OS/390, V7).

-debug

Specifies that deployment code will be compiled with debug information.

-keep

Controls the disposition of the temporary files that are created (that is, the Eclipse workspace) when the ejbdeploy command has run. Without this option, the Eclipse workspace is deleted when the command has completed.

-ignoreErrors

Specifies that processing should continue even if validation errors are detected.

-quiet

During validation, suppresses status messages (but does not suppress error messages).

-nowarn

During validation, suppresses warning and informational messages.

-noinform

During validation, suppresses informational 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"

-35

If you want to use the top-down mapping rules for CMP entity beans that are used in the EJB deployment 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.

-40

Use the WebSphere Application Server 4.0 top-down mapping rules.

-target name

Specify a particular WebSphere run-time environment to compile your application against. Targeting your runtime will configure the JRE library to use, as well as configure the project's classpath to contain the WebSphere runtime libraries. The valid server names are:
WAS510 (WebSphere Application Server, V5.1)
WAS502(WebSphere Application Server, V5.02)
WAS501(WebSphere Application Server, V5.01)
WAS500(WebSphere Application Server, V5.0)

-trace

Generates additional progress messages to the console.

-sqlj

Note: This option is valid only on enterprise beans compliant with the 2.0 specification.
Enables you to use SQLJ instead of JDBC to make calls to a DB2 database. With the -sqlj option specified, the EJB deployment tool generates SQLJ code for your CMP beans to use SQLJ to access the database. It also automatically invokes the SQLJ translator to translate the SQLJ source files. Finally, an Ant script will be created by the EJB deployment tool to help you to customize the SQLJ profiles easily. You can run the Ant script against the profile to produce a DB2 package. These DB2 packages can be used at runtime to avoid extensive runtime checking. Once you have generated the deployment code for SQLJ using the EJB deployment tool, you will need to run the DB2 SQLJ profile customizer, db2sqljcustomize, against the generated .ser file, which is found in the subfolder of the websphere_deploy folder associated with the DB2 backend. Consult the DB2 documentation for more information on running the DB2 SQLJ profile customizer, or visit www7b.boulder.ibm.com/dmdd/zones/java/bigpicture.html (section SQLJ support).

-OCCColumn

Note: This option is valid only on EJB 2.x CMP entity beans when generating top-down mapping. Enables you to add a column to your relational database table for collision detection. The collision detection column is the additional database column reserved to determine if a record has been updated. Adding a column for collision detection is an alternative optimistic concurrency control scheme of including attributes in a predicate for optimistic access intents. To manage the collision detection column, you will need to provide your own database trigger implementation. The following are the result of adding a column for collision detection:
The data type of the collision detection column is a 64 bit integer.
The naming convention of the collision detection column has the following format: OCC_bean_name
The top-down mapping generates an extra relational column. This column can not be mapped to the enterprise bean.

Example: Running the ejbdeploy command:

ejbdeploy AccessEmployee.ear d:\deploydir AccessEmployee_sqlj.ear -dbvendor DB2UDB_V81 -keep -sqlj -cp "e:\sqllib\java\sqlj.zip"

Explanation:
We have DB2 Universal database (version 8.1 for Windows and UNIX) installed in e:\sqllib.

The ejbdeploy command takes the AccessEmployee.ear file (which has enterprise beans that are compliant with the EJB 2.0 specification) as input and produces the AccessEmployee_sqlj.ear as output. Since the -sqlj option is used, SQLJ is used instead of JDBC in the generated code to make calls to DB2.

When ejbdeploy runs, it creates an Eclipse workspace in the directory that you specify as the working directory: d:\deploydir. When it has completed running, it deletes this workspace. However, the -keep option causes ejbdeploy to end without deleting the workspace.

Related concepts
enterprise beans on either a test or production server, you need to generate deployment code for the enterprise beans. You can do this using the EJB deployment tool. You can either use the command-line interface that it provides or you can invoke it from the workbench.">EJB deployment tool
SQLJ:">Requirements for deploying EJB applications using SQLJ
SQLJ support enables you to build and run SQLJ applets and applications. The DB2 SQLJ profile customizer, db2sqljcustomize, is one of the components of SQLJ, the other two components being the translator and the run time.">DB2 SQLJ profile customizer

Related tasks
EJB deployment tool provides a command-line interface that you can use to generate enterprise bean deployment code. 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.">Generating EJB deployment code from the command line