Migrate enterprise bean code to the supported specification

 

Overview

Support for V2.1 of the EJB specification is added for V6 of this product. Migration of enterprise beans deployed in Versions 4 or 5 of this product is not generally necessary; Versions 1.1 and 2.0 of the EJB specification are still supported. Follow these steps as appropriate for your application deployment.

 

Procedure

  1. Modify enterprise bean code for changes in the specification.

    • For V1.0 beans, migrate at least to V1.1.

    • As stated previously, migration from V1.1 to V2.x of the EJB specification is not required for redeployment on this version of the product. However, if your application requires the capabilities of Version 2.x, migrate your V1.1-compliant code.

      Note: The EJB V2.0 specification mandates that prior to the EJB container's running a findByMethod query, the state of all enterprise beans enlisted in the current transaction be synchronized with the persistent store. (This is so the query is performed against current data.) If V1.1 beans are reassembled into an EJB 2.x-compliant module, the EJB container synchronizes the state of V1.1 beans as well as that of V2.x beans. As a result, you might notice some change in application behavior even though the application code for the V1.1 beans has not been changed.

  2. You might have to modify code for some EJB 1.1-compliant modules that were not migrated to Version 2.x. Use the following information to help you decide.

    • Some stub classes for deployed enterprise beans have changed in the Java 2 Software Development Kit, V1.4.1.

    • The task of generating deployment code for enterprise beans changed significantly for EJB 1.1-compliant modules relative to EJB 1.0-compliant modules.

    For detailed information about source and binary compatibility between deployed versions, see Enterprise beans: Resources for learning.

  3. Ensure WebSphere Application Server 32-bit to 64-bit compatibility. For a "pure" Java application this is not an issue. However, if your application code utilizes the Java Native Interface (JNI) code, you should be aware of the following: the JNI allows Java code running in a virtual machine to operate with applications and libraries written in other languages, such as C, C++, and assembly. So, if your J2EE application uses JNI in a 32-bit environment, your code must be recompiled in the 64-bit environment. It is possible that the JNI calls could be different after the compilation, as the JNI specifications can change from version to version.

  4. Reassemble and redeploy all modules to incorporate migrated code.

 

See also


Migrating enterprise bean code from V1.0 to V1.1
Migrating enterprise bean code from V1.1 to V2.1
Adjusting exception handling for EJB wrappered applications migrating from v5 to v6

 

See Also


Enterprise beans

 

Related Tasks


Migrating a V4.0 data access application to v6
Task overview: Using enterprise beans in applications

 

See Also


Enterprise beans: Resources for learning