Exercises
The job agency case study defines a complete set of Session beans, and Entity beans. All of the Entity beans except the Applicant bean are implemented using CMP; the Applicant bean has been implemented using BMP. The exercise is to implement an Applicant Entity bean to use CMP. The source code and deployment descriptors can be found under day07exercise, and the directory structure is the same as yesterday.
In more detail, the fields of the Applicant bean need to be converted into either cmp-fields or cmr-fields:
login This is the primary key for the Applicant Entity bean and will be a cmp-field.
location cmr-field to the Location bean. There will be a one-to-many relationship between Location to Applicant.
skills cmr-field to the Skill bean. There will be a many-to-many relationship between the Applicant and Skill beans.
You should find that the Job CMP Entity bean acts as a good model for your new version of the Applicant bean. One difference is in the primary key. The Job bean required a JobPK because it had a composite primary key. For your Applicant bean, there is no custom primary key, so you will need to nominate the login cmp-field as its primary key using the primkey-field element in the deployment descriptor. Another related difference is that the Job bean has to deal with ensuring that its customer cmp-field is a valid identifier for a Customer. Your Applicant bean will not have this complication.
There should be no need to change the Agency and Register Session beans that call the Applicant bean, because it is only the internal implementation that is changing, not the interfaces.
The steps you should perform are as follows:
1. |
If you didn't do so earlier today, convert the Agency database to its CMP version. The steps to do this were described in the “A Quick Word about the Case Study Database” section. |
2. | |
3. |
Update the ApplicantBean class; base this on JobBean. |
4. |
The CMR relationships that will be built will be bi-directional. This is needed because, otherwise, the code generated by the J2EE RI fails to compile. So, in each of LocationBean and SkillBean, uncomment the getApplicants() and setApplicants() methods. Note that these have not been exposed in the respective interfaces. |
5. |
Build the enterprise application (agency.ear in the jar directory) and then load it into deploytool. Delete the Applicant bean from the enterprise application, and then add it in again into the data_entity_ejbs
ejb-jar. As you add it, you can specify that it is a CMP bean. |
6. | |
7. |
Add a many-to-many relationship from Applicant to Skill. Make the relationship bi-directional. |
8. |
Add a many-to-one relationship from Applicant to Location. Make the relationship bi-directional. |
9. |
Use the deploytool's Descriptor Viewer dialog to save the XML deployment descriptor. |
10. |
Now deploy the enterprise application (from the deploytool
GUI), providing the necessary auxiliary deployment information in the wizard that is displayed. Test your program by using the AllClients client, run with run
unAll. |
11. |
Optionally, use WinZip or equivalent to extract the auxiliary deployment descriptor and save as ddagency_ea-sun-j2ee-ri.xml from the agency.ear file previously generated. Then re-build and deploy using builduildAll and builddeploy. |
Good luck. A working example can be found in day07agency.