Programming WebLogic Enterprise JavaBeans
|
|
EJBGen is an Enterprise JavaBeans 2.0 code generator. If you annotate your Bean class file with javadoc tags, you can use EJBGen to generate the Remote and Home classes and the deployment descriptor files for an EJB application.
BEA recommends that you use EJBGen to generate deployment descriptors; this BEA best practice allows for easier and simpler maintenance of EJBs. If you use EJBGen, you have to write and annotate only one bean class file, which simplifies writing, debugging and maintenance. If you use WebLogic Workshop as a development environment, WebLogic Workshop automatically inserts EJBGen tags for you. These sections provide instructions on using EJBGen and define EJBGen command options and tag.
These sections describe how to process an annotated bean file using EJBGen:
As of WebLogic Server 8.1 SP02, EJBGen and associated classes are not included in weblogic.jar; instead, they are provided as a separate archive—ejbgen.jar in the WL_HOME/server/lib of the WebLogic Server distribution. To use EJBGen, put ejbgen.jar in your CLASSPATH.
If you have installed BEA WebLogic 8.1 examples, see WL_HOME\samples\server\examples\src\examples\ejb20\relationships for an example application called Bands that uses EJBGen.
Use this command to run EJBGen on a bean source file:
javadoc -docletpath ejbgen.jar -doclet weblogic.tools.ejbgen.EJBGen (YourBean).java
If you do not have ejbgen.jar in your classpath, add the path to weblogic.jar as follows:
javadoc -docletpath <path_to_ejbgen.jar> ejbgen.jar -doclet weblogic.tools.ejbgen.EJBGen (YourBean).java
If you are invoking EJBGen for an EJB that has relationships with other EJBs, invoke the related EJBs by naming them, following your EJB, in the invocation, as follows:
javadoc -docletpath ejbgen.jar -doclet weblogic.tools.ejbgen.EJBGen (YourBean).java (RelatedBean).java
Table D-1 defines EJBGen command options.
Table D-1 EJBGen Command Options
|
If invoked with this option, EJBGen will not generate any classes but will search the classes supplied on the command line for tags that are not valid EJBGen tags. |
||
|
The directory under which all the descriptor files will be created, relative to the output directory specified with the -d [directory] option. |
||
|
If specified, EJBGen prints out the detailed documentation for this tag, including all the recognized attributes. Note that even though this option does not need any source file, you still need to specify an existing |
||
|
Print out all the tags known by EJBGen. Note that even though this option does not need any source file, you still need to specify an existing |
||
|
Force the generation of all files regardless of time stamps. |
||
|
If this flag is set, EJBGen ignores the package name of the Java files it generates and creates those in the output directory as specified by the -d flag (or in the current directory if no -d was specified). |
||
|
The prefix to use for @remote-jndi-name and @local-jndi-name |
||
|
The suffix to use for @remote-jndi-name and @local-jndi-name |
||
|
If this flag is set, EJBGen will generate deployment descriptors compatible with the Public Final Draft 1 of the EJB 2.0 specification. You should use this flag if you are using any version anterior to Weblogic 6.1. |
||
|
If this flag is set, EJBGen will generate deployment descriptors compatible with the Public Final Draft 2 of the EJB 2.0 specification. You should use this flag if you are using any version anterior to Weblogic 6.1. |
||
|
The name of a property file that EJBGen reads to define substitution variables. See Using Property Files with EJBGen. |
||
|
The prefix to use when generating the remote EJB home class. |
||
|
The suffix to use when generating the remote EJB home class. |
||
|
If specified, the |
||
|
Use this flag to specify that EJBGen generate WebLogic Server 7.0 deployment descriptors. |
||
|
Use this flag to specify that EJBGen generate WebLogic Server 7.0 deployment descriptors. |
||
|
Use this flag to specify that EJBGen generate WebLogic Server 7.1 deployment descriptors. |
||
|
Use this flag to specify that EJBGen generate WebLogic Server 8.1 deployment descriptors. |
||
|
Use this flag to specify that EJBGen generate WebLogic Server 9.0 deployment descriptors. |
||
|
The encoding to use when generating XML files (default: UTF-8). |
If an EJBGen class contains value types (e.g., parameter values, return values) that are Java classes that have not been compiled, then Javadoc will output what appear to be javac compilation errors, as in Listing 8-6:
Listing 8-6 Sample Javadoc Output When Value Type Classes Are Uncompiled
[javadoc]
C:\toddk\dev\issues\cr100528\src\test\po\PurchaseOrderBean.java:29: cannot resolve symbol [javadoc] symbol : class PurchaseOrder [javadoc] location: class test.po.PurchaseOrderBean [javadoc] public boolean submitPO(PurchaseOrder po) throws SubmitException {
[javadoc]
[javadoc] C:\toddk\dev\issues\cr100528\src\test\po\PurchaseOrderBean.java:29: cannot resolve symbol [javadoc] symbol : class SubmitException [javadoc] location: class test.po.PurchaseOrderBean [javadoc] public boolean submitPO(PurchaseOrder po) throws SubmitException {
These are Javadoc warnings, not errors. Because the error messages resemble javac compiler errors, it is easy to interpret them incorrectly as errors. Javadoc returns with an exit status that indicates success; therefore the Ant EJBGen task does not cause the build to fail.
These sections describe key EJBGen features and how to use them:
By default, EJBGen generates the following files:
You can selectively disable the generation of these files by using the @ejbgen:file-generation tag. This can be done on a per-bean basis. The following code sample suppresses value class generation:
/**
* @ejbgen:file-generation
* value-class = False
*/
Note: The -noValueClasses, -noRemoteInterfaces or -noLocalInterfaces, these command-line options override any tag found on the beans.
EJBGen can gather information for generation from property files, as discussed in this section.
Use the -propertyFile option to tell EJBGen to parse a properties file. Listing 8-7 illustrates a sample property file.
Listing 8-7 Sample EJBGen Property File
# property-file
#
remote-jndi-name = Account
Use the following syntax to invoke EJBGen with the -propertyFile option:
javadoc -docletpath ejbgen.jar -doclet EJBGen -propertyFile property-file AccountBean.java
EJBGen recognizes two kinds of variables in a properties file: user variables and predefined variables.
EJBGen tags can use variables instead of strings. These variables must be enclosed with "${" and "}", as in Listing 8-8.
Listing 8-8 User Variables in Place of Strings
@ejbgen:jndi-name
remote = ${remote-jndi-name}
Variables can be used anywhere after an EJBGen tag, so they can contain whole tag definitions, as in Listing 8-9.
Listing 8-9 User Variables as a Whole Tag Definition
@ejbgen:jndi-name
${jndi-name-tag}
#
#
# property-file
#
jndi-name-tag = remote = RemoteAccount local = LocalAccount
EJBGen recognizes a number of predefined variables. These variables are not supposed to be used in tags but EJBGen will use them at various places depending on their role. Here is the list of recognized variables:
remote.baseClassIf specified, the value of this variable will be used as the base class for all generated remote classes.
home.baseClass
local.baseClassIf specified, the value of this variable will be used as the base class for all generated local classes.
localHome.baseClassIf specified, the value of this variable will be used as the base class for all generated local home classes.
value.baseClassIf specified, the value of this variable will be used as the base class for all generated value classes.
value.packageIf specified, the value of this variable will be used as the package for all generated value classes.
value.interfacesYou can make these variables more specific by prefixing them with an EJBName. For example, consider the following property file:
#
# property-file
#
Account.home.baseClass = BaseAccountHome
home.baseClass = BaseHome
value.package = value
containerManaged.value.package=valuePackageForContainerManaged
All homes generated by EJBGen extend the class BaseHome except the home of EJB "Account", which extends BaseAccountHome.
When you specify an attribute that contains spaces, surround the attribute value with double quotes. For example:
group-names = "group1, group2"
One of the main features in EJBGen 2.0 is tag inheritance. You inherit EJBGen annotations the same way you do it in Java. For example, assume that you have an EJB named AccountEJB with a base class BaseAccount, as in Listing 8-10:
/***@ejbgen:jndi-name*remote="BaseRemote"
*/
public class BaseAccount implements EntityBean {
// ...
}
/***@ejbgen:entity*ejb-name = containerManaged*table-name = ejbAccounts*data-source-name = examples-dataSource-demoPool*
*Note that we inherit the JNDI name defined in BaseAccount
*/
public class AccountEJB extends BaseAccount {
// ...
You can also inherit attributes. This is a very powerful feature with a lot of potential uses. For example, you could define a setting common to all your EJB's, such as max-beans-in-cache, as in Listing 8-11.
Listing 8-11 Attribute Inheritance
/***@ejbgen:entity*max-beans-in-cache = 300*/
public class BaseAccount implements EntityBean {
// ...
}
Then, you define your entity bean as follows:
/***@ejbgen:entity*ejb-name = containerManaged*table-name = ejbAccounts*data-source-name = examples-dataSource-demoPool*// automatically inherit the attribute max-beans-in-cache = 300
**/
public class AccountEJB extends BaseAccount {
// ...
Of course, you still have the ability to modify the inherited value. For example, for a specific bean, you could change the default value of max-beans-in-cache from 300 to 400:
/***@ejbgen:entity*ejb-name = containerManaged*table-name = ejbAccounts*data-source-name = examples-dataSource-demoPool*max-beans-in-cache = 400*// the above setting overrides the one defined in the base class
*
*/
public class AccountEJB extends BaseAccount {
// ...
These sections contain example source code annotated with EJBGen tags.
This example shows an CMP EJB 2.0 entity bean file with annotations that EJBGen can use to generate the remote and home interfaces and the deployment descriptor files. AccountBean.java is the main bean class.
/**
* @ejbgen:entity
* ejb-name = AccountEJB-OneToMany
* data-source-name = examples-dataSource-demoPool
* table-name = Accounts
* prim-key-class = java.lang.String
*
* @ejbgen:jndi-name
* local = one2many.AccountHome
*
* @ejbgen:finder
* signature = "Account findAccount(double balanceEqual)"
* ejb-ql = "WHERE balance = ?1"
*
* @ejbgen:finder
* signature = "Collection findBigAccounts(double balanceGreaterThan)"
* ejb-ql = "WHERE balance > ?1"
*
* @ejbgen:relation
* name = Customer-Account
* target-ejb = CustomerEJB-OneToMany
* multiplicity = many
* cmr-field = customer
*
*/
abstract public class AccountBean implements EntityBean {
/**
* @ejbgen:cmp-field column = acct_id
* @ejbgen:primkey-field
* @ejbgen:remote-method transaction-attribute = Required
*/
abstract public String getAccountId();
abstract public void setAccountId(String val);
// ....
}
This example illustrates the two types of EJBGen tags: class tags and method tags, depending on where you can use them.
After completing the file, invoke EJBGen through the following Javadoc command:
javadoc -docletpath weblogic.jar -doclet weblogic.tools.ejbgen.EJBGen AccountBean.java
The Javadoc command generates the following files:
EJBGen Tag Reference defines the EJBGen tags you can use to annotate your bean class file.
By default, entity beans are mapped to one table, with the attribute table-name on the tag @ejbgen:entity. If you want to map your entity bean to more than one table, you can use the table-name attribute on individual @ejbgen:cmp-fields. All the container-managed persistence fields that do not have a table-name attribute will use the table specified on @ejbgen:entity (which can therefore be considered as the "default" table).
If you want to map an entity bean to several tables, you need to specify a comma-separated list of tables in the table-name attribute (and also on a column). For example:
Make sure that the number of tables matches the number of columns, and that the columns exist in the corresponding table.
You can specify relationship caching elements with the @ejbgen:relationship-caching tag. This XML element can be nested (recursive). In other words, you can specify a tree representing all the relationship elements that you want to see cached.
In order to support this tree structure, @ejbgen:relationship-caching has two attributes, id and parent-id. These attributes do not correspond to any XML, they simply allow you to specify your tree structure.
For example, if a caching-element A needs to have two children elements B and C, all you need to specify is an id for A (say "root0") and a parent-id for B and C equal to that name.
Listing 8-12 illustrates specifying relationship caching.
Listing 8-12 Specifying Relationship Caching
* @ejbgen:relationship-caching-element
* caching-name = cacheMoreBeans
* cmr-field = employee
* group-name = emp-group
* id = A
*
* @ejbgen:relationship-caching-element
* caching-name = cacheMoreBeans
* cmr-field = employee_ssn
* group-name = emp-group
* parent-id = A
*
* @ejbgen:relationship-caching-element
* caching-name = cacheMoreBeans
* cmr-field = employee_zip
* group-name = emp-group
* * parent-id = A
Unidirectional relationships are achieved by specifying only the first two parameters of the relation tag (no CMR_field, no joint table).
Many-to-many relationships must specify an extra table (parameter "joint table") which must contain at least two columns. The names of these columns must match the names of the columns containing the foreign keys of the two beans being joined.
If you have EJB's based on a version of the EJB 2.0 specification that predates PFD2, you will need to update them. As of PFD2, relationships must be based on local interfaces, not remote ones. Here are the steps you need to take up upgrade your EJB's:
@ejbgen:local-method tags to any method you want to see appear on the local home interface. A method can have both @ejbgen:local-method and @ejbgen:remote-method.
This section provides a complete reference for EJBGen tags you can use to annotate your bean class file.
|
The column where this CMP field will be mapped. See Mapping an Entity Bean to Several Tables with EJBGen. |
||
|
|
||
|
Comma-delimited names of the groups this field belongs to. Surround the list of group names with double quotes. |
||
|
The number where this field must appear in signatures and constructors. For this ordering to work, all cmr and cmp fields must set this attribute to a distinct numeric value. |
||
|
|
||
|
|
||
|
The table(s) where this field should be mapped. Mapping an Entity Bean to Several Tables with EJBGen. |
|
The name of the client JAR to generate. If more than one EJB has this tag, only one of the specified JAR files is included in the deployment descriptor. |
|
|
Applicable to: Session and entity beans
Applicable to: Message-driven beans