Express (Distributed operating systems), v8.0 > Reference > Command-line utilities > EJB deployment tool > Reference
The ejbdeploy command
Before you can successfully run your enterprise beans at 1.1, 2.0, or 2.1 specification-level on either a test or production server, generate deployment code for the enterprise beans. See Tolerating EJB at 3.0 (or later) specification-level section on how the ejbdeploy command handles enterprise beans at 3.0 (or later) specification-level. This reference topic describes what is the syntax, expected behavior, and descriptions of each of the parameters for running the ejbdeploy command from a command line.
This topic is divided into the following sections:
- Before you begin
- Syntax
- Behavior
- Tolerating EJB at 3.0 (or later) specification-level
- Parameters
- Example
Before you begin
Start in WAS V8.0.0.1 release, you can modify the heap size available for the EJB deployment tool by setting the EJBDEPLOY_JVM_HEAP environment variable. For more details, see the Modify the JVM heap size available to the EJB deployment tool topic.
Syntax
Use the following command and the optional parameters, when the schema and map are provided in the input EAR or JAR file:
ejbdeploy input_EAR_name|input_JAR_name working_directory output_EAR_name|output_JAR_name [-bindear "options"] [-cp classpath] [-codegen] [-debug] [-keep] [-ignoreErrors] [-quiet] [-nowarn] [-noinform] [-rmic "options"][-trace] [-sqlj] [-outer] [-complianceLevel "1.4"|"5.0"|"6.0"][-DgenInheritancePerfEnhancement]
Use the following command and the optional parameters, when the schema and map are not available in the input EAR or JAR file, and a top-down mapping approach is needed:
ejbdeploy input_EAR_name|input_JAR_name working_directory output_EAR_name|output_JAR_name [-bindear "options"] [-cp classpath] [-codegen] [-dbschema "name"] [-dbvendor name] [-debug] [-keep] [-ignoreErrors] [-quiet] [-nowarn] [-noinform] [-rmic "options"][-trace] [-sqlj][-OCCColumn] [-outer] [-complianceLevel "1.4"|"5.0"|"6.0"] [-DgenInheritancePerfEnhancement]
The -dbschema, -dbvendor, and -OCCColumn 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 file 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.
Behavior
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.
If the -dbvendor option is not set, the default database back end is DB2UDB_V95. To set a different database back end, use the -dbschema and -dbvendor options to specify your choice. A data definition language (DDL) file, Table.ddl, is created for the database back end set in the -dbvendor option, when you run the ejbdeploy command. However, you can specify only one back end at a time using the -dbvendor option.
If the -dbvendor option is specified for mapped jars, for example the JAR file already contains a DB2 back end and you specify -dbvendor ORACLE on the command line; in previous releases of the product, rather than getting a second back end, the database vendor specification was ignored. Starting in WAS V6.0.2, the following changes were made for the scenario where the -dbvendor option is specified for a mapped jar:
For 2.x CMP beans where multiple mappings to different database vendors are supported:
- If the value for the -dbvendor option is different from the existing maps, then a new top-down map is generated, and that becomes the current back end.
- If the value for the -dbvendor option is the same as one of the existing maps, then that map becomes the current
back end, and the following message is issued:
A mapping to the database vendor, database_vendor, already exists. Setting the current backend id to backend_id.
For 1.1 CMP beans that can only be mapped once:
- If the value for the -dbvendor option is the same as the existing map, then the following message is issued and deployment continues:
A mapping to the database vendor, database_vendor, already exists. Using the existing map to continue the generation of EJB deployment code.
- If the value for the -dbvendor option is different as the existing map, the following exception is thrown and deployment stops:
A mapping already exists for a different database vendor. Action: To generate deployment code against this existing map, for the -dbvendor argument of the ejbDeploy command, try verifying and matching the backend id to the existing map.
Another general behavior of the ejbdeploy command is if the abstract fields or bean name for CMP entity beans use any SQL
reserved keywords, the top-down mapping adds a numeric suffix to the column name when generating the data definition language file (Table.ddl).
This is to avoid SQL command conflicts when SQL reserved words are used as column names. For a list of SQL reserved words, see the topic
SQL reserved keywords.
Tolerating EJB at 3.0 (or later) specification-level
When you install the WAS V6.1 with Feature Pack for EJB 3.0 or WAS v7.0 (or later), the ejbdeploy command-line tool tolerates artifacts at Java EE 5 or later, such as EJB 3.0 or 3.1. In terms of tolerance, the ejbdeploy tool allows the presence, but does not generate deployment code for artifacts at Java EE 5 (or later) specification-level.For EJB 3.0 (or later) specification-level, you no longer need to generate the EJB deployment code. The runtime of the server automatically handles generating the required deployment code.
The following lists the general behavior of the ejbdeploy command when issued with the presence of Java EE 5 (or later) artifacts:
- Tolerates EAR 5.0 (or later) files and EJB 3.0 (or later) JAR
files
- Tolerates EAR files with Java 2 Platform Enterprise Edition (J2EE) 1.4 deployment descriptors that contains EJB 3.0 (or later) JAR files. Deployment code is generated only for EJB at 1.1, 2.0, or 2.1 specification-level, such as Container-Managed
Persistence (CMP) entity beans. However, deployment code is not generated for EJB beans at 3.0 (or later) specification-level, such as Session
beans, Message-Driven Beans (MDB) or Bean-Managed Persistence (BMP)
- If the -complianceLevel option for the ejbdeploy
command is not specified, in any of the following cases the default -complianceLevel setting is Java developer kit V5.0, "5.0":
- An EAR or JAR file that contains Java EE 5 (or later) or EJB 3.0 (or later) deployment descriptor files
- An EAR file without any deployment descriptor files
All other cases, the -complianceLevel setting defaults to Java developer kit V1.4, "1.4"
If you are generating deployment code for J2EE 1.4 EAR or JAR files that contain source code files which uses the new language features in Java developer kit 5.0 (or later), specify one of the following parameters when running the ejbdeploy command:
Parameters
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. Verify the .class files of home and remote classes of each enterprise bean 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 run 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 the application on the server.
-cp "path\myJar1.jar;path\myJar2.jar;path\myJar3.jar"
-cp "path/myJar1.jar:path/myJar2.jar:path/myJar3.jar"
Tip: If you specified the -sqlj option, 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.
- Import code from the input JAR or EAR file
- Generate the deployment code
- Export code to the output JAR or EAR file
It does not compile the generated deployment code or run remote method invocation compiler (RMIC). Since Java source code is not typically exported in the output EAR or JAR, this is the only way to save the generated code.
- The default is DB2UDB_V95 (DB2 V9.5
for Linux, UNIX, and Windows)
- If -sqlj is specified, this argument supports the following database vendors:
- DB2UDB_V98
- DB2UDB_V97
- DB2UDB_V95
- DB2UDB_V91
- DB2UDB_V82
- DB2UDB_V81
- DB2UDBOS390_V10
- DB2UDBOS390_V9
- DB2UDBOS390_V8
- DB2UDB0S390_NEWFN_V8
- DB2UDB_V98
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 is created by the EJB deployment tool to help you to customize the SQLJ profiles easily. We 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 we have generated the deployment code for SQLJ using the EJB deployment tool, 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 back end. Consult the DB2 documentation for more information about running the DB2 SQLJ profile customizer, or visit //publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=/ ://www.ibm.com/developerworks/data/zones/java/bigpicture.html (section SQLJ support).
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, 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 cannot be mapped to the enterprise bean.
If you specify this parameter for deploying a J2EE 1.4 application, this option is ignored because the specification for J2EE 1.4 defines the INNER semantics be used for J2EE 1.4 applications.
- An EAR or JAR file that contains Java EE 5 (or later) or EJB 3.0 (or later) deployment descriptor files
- An EAR file without any deployment descriptor files
All other cases, the -complianceLevel setting defaults to Java developer kit V1.4, "1.4"
-
%JAVA_HOME%\bin\java" -DgenInheritancePerfEnhancement=true -Ditp.loc="%ITP_LOC%" -Dorg.osgi.framework.bootdelegation=* -Dwas.install.root="%WAS_HOME%" -Dwebsphere.lib.dir="%WAS_HOME%\lib" -Dws.ext.dirs="%WAS_HOME%\eclipse\plugins\j2ee.javax_1.4.0";"%WAS_HOME%\eclipse\plugins\com.ibm.ws.runtime.eclipse_1.0.0";"%WAS_EXT_DIRS%" -Dcom.ibm.sse.model.structuredbuilder="off" -cp "%ejbd_cp%" -Xbootclasspath/a:"%bootpath%" -Xj9 -Xquickstart -Xverify:none -Xms256M -Xmx256M %WAS_DEBUG% com.ibm.etools.ejbdeploy.EJBDeploy %*
-
$JAVA_CMD -Xbootclasspath/a:$ejbd_bootpath -Xms256m -Xmx256m -DgenInheritancePerfEnhancement=true -Dws.ext.dirs=WAS_HOME/eclipse/plugins/j2ee.javax_1.4.0:WAS_HOME/eclipse/plugins/com.ibm.ws.runtime.eclipse_1.0.0:$WAS_EXT_DIRS -Dwebsphere.lib.dir=WAS_HOME/lib -Dwas.install.root=WAS_HOME -Ditp.loc=$ITP_LOC -Dorg.osgi.framework.bootdelegation=* -Dejbdeploy.user.install.root=$USER_INSTALL_ROOT/ejbdeploy $USER_INSTALL_PROP -Dcom.ibm.sse.model.structuredbuilder="off" -cp $ejbd_cp $EJBDEPLOY_JVM_OPTIONS $WAS_DEBUG com.ibm.etools.ejbdeploy.EJBDeploy "$@"
Example
ejbdeploy AccessEmployee.ear d:\deploydir AccessEmployee_sqlj.ear -dbvendor DB2UDB_V95 -keep -sqlj -cp "e:\sqllib\java\sqlj.zip"
Explanation:
We have DB2 V9.5 for Windows, Linux 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.
Generate deployment code for enterprise beans from the command line
Modify the JVM heap size available to the EJB deployment tool
Related
SQL reserved keywords
Run the ejbDeploy command can generate compilation errors for DB2 V9 for z/OS
Feedback