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.
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 so 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. 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.
- Reassemble and
redeploy all modules to incorporate migrated code.