Limitations of EJB 1.x - 2.x development tools

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


Feedback