Support for Version 2.1 of the Enterprise JavaBeans (EJB) specification
is added for Version 6 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.
Before you begin
About this task
Follow these steps as appropriate for your application deployment.
Procedure
- Modify enterprise bean code for changes in the specification.
- For Version 1.0 beans, migrate
at least to Version 1.1.
- As stated previously, migration from Version 1.1 to Version 2.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 Version 1.1-compliant
code.
Note: The EJB Version 2.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 done so that the query is performed against
current data. If 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.
- 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, Version 1.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.
-
Ensure WebSphere Application Server 32-bit to 64-bit compatibility.
This is not an issue for a pure Java application. However, if
your application code utilizes the Java Native Interface (JNI) code, 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. Therefore, 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.
- Reassemble and
redeploy all modules to incorporate migrated code.