Presented by developerWorks, your source for great tutorials

ibm.com/developerWorks

that all of its children in the relationship are also deleted with the

target cascade delete

attribute. Notice that you also specified the

target role name. The attributes that start with target are really only needed for one

way relationships (unidirectional). Since this example is bi directional you could have

left this out. The multiplicity of the relationship is based on the return type of the getter

method in the cmr field. Since

getEmployees

returns a Collection, XDoclet infers that

the multiplicity of

Employee

is many.

No matter how flat a pancake is, its always got two sides just like an CMR relationship.

Here is the other side of the CMR relationship.

public abstract class EmployeeBean implements EntityBean {

...

/**

* @return Return the group this user is in.

*

* @ejb.interface method view type="local"

*

* @ejb.transaction type="Required"

*

* @ejb.relation

*

name="EmployeesInADeptartmentRelation"

*

role name="EmployeeInADept"

*

target role name="DeptHasEmployees"

*

*/

public abstract Dept getDept();

/** @ejb.interface method view type="local" */

public abstract void setDept(Dept dept);

Again the target attribute is a little bit of extra information that is really only needed in

the case on a unidirection relationship, but it is here for good measure. Notice that the

Relationship name is the same as the relationship name on the Dept side of the

relationship. This is what XDoclet uses to correlated the two members of the

relationship.

The above ejb.relation tags would generate the following entries in the deployment

descriptor.

EmployeesInADeptartmentRelation

EmployeeInADept

Enhance J2EE component reuse with XDoclets

Page 39 of 49