Generating deploy code for enterprise beans from the command line

 

The following activities occur when you run the ejbdeploy command:

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.

 

Syntax

ejbdeploy input_JAR_name \
          working_directory \
          output_JAR_name \
          [-cp classpath] \
          [-codegen] \
          [-bindear:"options"] \
          [-dbname name] \
          [-dbschema name] \
          [-dbvendor name] \
          [-debug] \
          [-keep] \
          [-ignoreErrors] 
          [-quiet] \
          [-nowarn] \
          [-noinform] \
          [-rmic "options"] \
          [-35]  \
          [-trace] \
          [-sqlj]

 

Command arguments

ejbdeploy

The command to generate deploy 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 deploy code; for example, c:\ejb\inputJARs\myEJBs.jar. (This argument is required.) If your input JAR or EAR file contains CMP beans, the ejbdeploy command automatically creates the schemas and mappings for the CMP beans. 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.

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 deploy code generation is complete. (If you do not want the working directory to be removed when the deploy code generation is complete, use the -keep option.)

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

-codegen

Restricts the ejbdeploy command to just (a) importing code from the input JAR or EAR file (b) generating the deploy code, and (c) exporting code to the output JAR or EAR file. It will not compile the generated deploy 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. These options are described in the WebSphere® Application Server documentation. The options must be separated by a space and enclosed in double quotation marks. For example:
-bindear "xx yy zz"

-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 by WebSphere® Studio, 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_V71 (DB2 for Windows, V7.1)
     DB2UDBWIN_V72 (DB2 for Windows, V7.2)
     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_V73 (Informix Dynamic Server.2000, V7.3)
     INFORMIX_V92 (Informix Dynamic Server.2000, V9.2)
     INFORMIX_V93 (Informix Dynamic Server.2000, V9.3)
     SYBASE_V1192 (Sybase Adaptive Server Enterprise, V11.9.2)
     SYBASE_V1200 (Sybase Adaptive Server Enterprise, V12.0)
     SYBASE_V1250 (Sybase Adaptive Server Enterprise, V12.5)
     MSSQLSERVER_V7 (Microsoft SQL Server, V7)
     MSSQLSERVER_2000 (Microsoft SQL Server 2000)
     CLOUDSCAPE_V50(Cloudscape, V5.0)

-debug

Specifies that deploy code will be compiled with debug information.

-keep

Retains the working directory after the ejbdeploy command has run.

-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 Deploy 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 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.)

-trace

Generates trace information.

-sqlj

Enables you to use SQLJ instead of JDBC to make calls to a DB2 database. If you use SQLJ, the EJB Deploy 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. For more information about the DB2 implementation of SQLJ, consult the DB2 Application Development guide, or visit www.ibm.com/software/data/db2/java.

Code validation

When the EJB validator issues an error, warning, or information message, the location of the source of the message is displayed in the following format (an error message is used as an example):

[Error:] JAR_name(location): message_text

where JAR_name is the name of the archive file, message_text is the text of the message, and location identifies the source of the message.

The location will either be a number or text. It defaults to a line number if a line number is available as a result of .java source files residing in the archive. For example, if the line number is 101, the message would appear as follows:

[Error:] JAR_name(101): message_text

If no line number is available, a text description of the location is provided. A message on a method, for example, would be displayed like this:

[Error:] JAR_name(Method: fully_qualified_method_name, Class: fully_qualified_name_of_the_class_that_contains_the_method): message_text

Migration

If you want to migrate an EJB 1.0 JAR to WebSphere® Application Server and have modified the exisiting generated deploy code to get it to work with a specific database vendor (for example, changing the case of column names to mixed case), that change will not be preserved when you redeploy the jar using the EJB deploy tool.

If you originally used VisualAge for Java to specify a mapping and generate the deploy code, then you will need to export the EJB project from VisualAge for Java as an EJB 1.1 JAR. This will preserve your mapping metadata and the case of table and column names.

 

® WebSphere is a trademark of the IBM® Corporation in the United States, other countries, or both.

 

® IBM is a trademark of the IBM Corporation in the United States, other countries, or both.