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:
- 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.)
- Open a command window and change to the directory where you installed the
EJB Deploy Tool.
- 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.
- 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.)
|
|