The ejbdeploy command

The EJB deployment tool provides a command-line interface that you can use to generate enterprise bean deployment code. The tool employs this command-line environment that enables you to run a build process overnight and have the deployment tool automatically invoked to generate your deployment code in batch mode.

Syntax

Example

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][-trace] [-sqlj]
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.) If your input JAR or EAR file contains CMP beans, theejbdeploy command automatically creates the schemas and mappings for the CMP beans, only if they do not exist. 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 or EAR file.

Tip: By default, a DB2 database is created once you run the ejbdeploy command. If you want to create a different type of database, use the -dbname , -dbschema, and -dbvendor options to specify your choice.

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 JAR or EAR files, you can use the -cp option to specify the class path of the other JAR or EAR files. Using the -cp option, you can specify multiple JAR or EAR files as arguments. However, the JAR or EAR 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 JAR file, sqlj.zip. The default path for this file is DB2_install_dir\java, for example, d:\sqllib\java\sqlj.zip on Windows.

-codegen
Restricts theejbdeploy 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.
-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" Note that the -dbschema, -dbname, -dbvendor, and -35 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, meaning that the options do not need to be respecified. 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.
-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_V72(DB2 for Windows, V7.2 and UNIX)
  • DB2UDB_V81(DB2 for Windows, V8.1 and UNIX)
  • DB2UDBOS390_V6 (DB2 for OS/390, V6)
  • DB2UDBOS390_V7 (DB2 for OS/390, V7)
  • DB2UDBISERIES (DB2 for iSeries)
  • ORACLE_V8 (Oracle, V8.0)
  • ORACLE_V9I (Oracle, V9.0I)
  • INFORMIX_V93 (Informix Dynamic Server.2000, V9.3)
  • SYBASE_V1200 (Sybase Adaptive Server Enterprise, V12.0)
  • SYBASE_V1250 (Sybase Adaptive Server Enterprise, V12.5)
  • MSSQLSERVER_2000 (Microsoft SQL Server 2000)
  • CLOUDSCAPE_V5 (Cloudscape, V5.0)

Note:

  • The default is DB2UDB_V72 (DB2 for Windows, V7.2 and UNIX)
  • If -sqlj is specified, we support DB2UDB_V81 (DB2 for Windows, V8.1 and UNIX), DB2UDBOS390_V6(DB2 for OS/390, V6), 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 compilation or validation errors are detected.
-quiet
Suppresses status messages (but does not suppress error messages).
-nowarn
Suppresses warning and informational messages.
-noinform
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
For CMP entity beans, the EJB deployment tool looks in the JAR or EAR 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 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. (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.)
-40
Use the WebSphere Application Server 4.0 top-down mapping rules.
-trace
Generates trace information.
-sqlj

Note: This option is valid only on enterprise beans compliant with the 2.0 specification.

Enables you to use SQLJ instead of JDBC in the generated code to make calls to a DB2 database. If you use SQLJ, the EJB deployment tool generates an Ant script and a SQLJ serialized profile. 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 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 customizer, or visit www7b.boulder.ibm.com/dmdd/zones/java/bigpicture.html (section SQLJ support).

Example: Running the ejbdeploy command:

Example

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. The -keep option causes ejbdeploy to end without deleting the workspace.

See the related task: Generating deployment code for enterprise beans from the command line



Searchable topic ID:   ejbdeploy
Last updated: Jun 21, 2007 10:55:55 PM CDT
http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp?topic=/

Library | Support | Terms of Use | Feedback