This product supports the Enterprise JavaBeans
(EJB) 3.1 specification.
Before you begin
There are no migration issues associated with using EJB 3.x beans. Existing applications
continue to run as-is and compile without error. Note: The EJB 3.0 and EJB 3.1 specifications have
deprecated the use of EJB 1.1 style entity beans. While using EJB 2.x and earlier modules in the
product has not yet been deprecated, you are encouraged to start migrating to Java™ Persistence API (JPA) or JDBC.
About this task
Follow these steps as appropriate for your application deployment.
Procedure
-
Modify enterprise bean code for changes in the specification.
You must migrate the Version 1.1 beans to Version 2.x beans and redeploy them on the product. For
more information, see Migrating enterprise bean code from Version 1.1 to Version
2.1.
Note: The EJB Version 2.0 specification mandates that before the EJB container runs a
findByMethod query, the state of all enterprise beans enlisted in the current transaction be
synchronized with the persistent store. This synchronization is done so that the query is performed
against current data. When Version 1.1 beans are reassembled into an EJB 2.x-compliant module, the
EJB container synchronizes the state of Version 1.1 beans, as well as that of Version 2.x beans. As
a result, you might notice some change in application behavior even though the application code for
the Version 1.1 beans has not been changed.
-
Ensure WebSphere® Application Server 64-bit
compatibility.
This is not an issue for a pure Java application.
However, if your application code uses the Java Native
Interface (JNI) code, be aware of the following considerations: 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. It is possible that the JNI
calls could be different after the compilation, as the JNI specifications can change from version to
version.
-
Reassemble and redeploy all modules to
incorporate migrated code.