This topic outlines current known limitations and restrictions
for the EJB 2.x tooling.
Problems generating deployment code when installation
path has multiple consecutive spaces
If
there are multiple consecutive spaces in any of the directories on
the path where the product is installed, generation of deployment
code fails.
EJB deployment code not deleted when changing a bean
class
In order to support multiple enterprise beans using
the same Java™ classes, the generated
deployment code is required to use a naming technique to make the
names of the generated deployment classes unique. The names are derived
from the names of the existing bean class, interfaces, and key classes.
If you generated the deployment code for a bean
and you want to change the name of any of these classes, you must
delete the deployment code first. If you do not delete the deployment
code first, the old, generated classes are not removed and might contain
compilation errors. This is true also if you change the type of your
primary key field using the Bean page of the EJB Deployment Descriptor
editor and selecting the Edit button beside the CMP fields section.
This automatically changes the key class to the type specified or
a new compound key is created if a primary key field is no longer
valid.
Running the ejbDeploy command may generate compilation
errors for DB2 V9 for z/OS
If
you have an enterprise bean (EJB) JAR file that contains mappings
to a DB2® V9 z/OS® back end (DB2UDBOS390_V9) along with back
ends from other database vendors and these back ends have mappings
to a collision detection column (OCC column), you might get compilation
errors when generating deployment code for the enterprise bean. See
Running the ejbDeploy command may generate compilation
errors for DB2 V9 for z/OS topic for details.
Deleting tables and schemas
If a table needs
to be deleted, use the Data perspective or the Enterprise Explorer
view of the Java EE perspective,
then all dependent links are also removed. Normally, do not use the
Navigator view (in the Resource perspective) or the Java EE Project Explorer view for deleting Java EE resources because dependencies
are not updated.
Unknown primary key is not
supported
The EJB tooling currently does not support the
Unknown primary key definition described in the EJB 2.0 specification.
The workaround is to define a specific primary key class.
Source page and EJB inheritance
If
you are modifying CMP entity beans in an inheritance hierarchy, use
the wizards and interface portions of the EJB deployment descriptor
editor, not the Source page. For example, if you want to add or remove
CMP fields or change the primary key field of a CMP bean, these fields
are synchronized by the tools for all inherited beans, in order to
keep the beans in compliance with the EJB specification. Such synchronization
may not occur if you change the source in the Source page.
Multiple output folders are not
supported for EJB projects
Specifying multiple output folders
for an EJB project is not supported. In the EJB project properties,
you can specify one default output folder for your source folders
on the build path. At the bottom of the Java Build
Path page, the Default output folder field allows you to enter a folder
path where the compilation output for this project resides. The default
output is used for source folders that do not specify an output folder.
A
possible workaround might be to create an EJB project for each of
your EJBs or sets of EJBs, then each EJB set would be self-contained
in a JAR with its own subsystem, allowing for a different output folder
for each EJB project. You can specify that EJB client projects are
created by default for new EJB projects.
Migrating EJB applications
- Cleaning up access beans when migrating beans from EJB 1.1 to
EJB 2.0. Because access beans are not supported for enterprise beans
that only have local client views, you need to do some manual cleanup
if you migrate a bean from EJB 1.1 to EJB 2.0 and add a local client
view and remove the remote client view:
- If you have a data class access bean, you must delete the factory
class associated with the bean.
- If you have a copy helper access bean, you need to delete the
access bean itself, delete the factory, and clean up any methods in
the bean class that might be invalid.
- Migrating EJB projects that contain binary classes. When you use
the Migration wizard to migrate an EJB project that contains one or
more binary Java classes (.class
files), the migration successfully migrates the project components
that contain source Java files
(.java files), but it does not migrate the binary classes. You need
to manually fix any errors.