Migrating code from EJB 1.1 to EJB 2.x

For projects converted from EJB 1.1 to EJB 2.x, steps must be taken to migrate existing EJB 1.1 code to EJB 2.x.

About this task

Note: EJB 2.x beans are only supported in an EJB 2.x project (although a 2.x project also supports 1.1 beans).

For any CMP 1.1 bean, replace each CMP field with abstract getXXX and setXXX methods. (Then the bean class needs to be abstract.)
For any CMP, create an abstract getXXX and setXXX method for the primary key.
For any CMP 1.1 finder method, create an EJBQL (EJB Query Language) method for each finder method.
Note: EJB Query Language has the following limitations in version 7.5 V6.0:
- EJB Query Language queries involving EJBs with keys made up of relationships to other EJBs appear as invalid and cause errors at deployment time.
- The IBM® EJB Query Language support extends the EJB 2.x specification in various ways, including relaxing some restrictions, adding support for more DB2® functions, and so on. If portability across various vendor databases or EJB deployment tool is a concern, then care should be taken to write all EJB Query Language queries strictly according to instructions described in Chapter 11 of the EJB 2.x specification.
Note: EJB Query Language has the following limitations in Rational® Application Developer V7.5:
- For EJB 1.1 level beans, IBM provides an extension for supporting finders based on EJBQL. When EJBs which use this are migrated to be 2.x EJBs, the old abstract schema name used in the EJBQL query does not match the abstract schema name that the migrator gives to the EJB. This results in errors in the problems view like "WQRY0025E: The abstract schema name ResultBean is not defined". The fix is to manually change the abstract schema name in the query to match that of the migrated EJB.
For any CMP 1.1 finder, return java.util.Collection instead of java.util.Enumeration.
For any CMP 1.1 bean, change all occurrences of this.field = value to setField(value) in ejbCreate() and elsewhere throughout the code.
Update your exception handling (rollback behavior) for non-application exceptions:
- Throw javax.ejb.EJBException instead of java.rmi.RemoteException to report non-application exceptions.
- In EJB 2.x and 1.1, all non-application exceptions thrown by the instance result in the rollback of the transaction in which the instance executed, and in discarding the instance.
Update your Exception handling (rollback behavior) for application exceptions:
- In EJB 2.x and 1.1, an application exception does not cause the container to automatically roll back a transaction.
- In EJB 1.1, the container performs the rollback only if the instance was invoked using the setRollbackOnly() method on its EJBContext object.
Update any CMP setting of application-specific default values to be inside ejbCreate (not using global variables, since EJB 1.1 containers set all fields to generic default values before calling ejbCreate which overwrites any previous application-specific defaults).