Limitations of EJB deployment

This topic outlines current, known limitations and restrictions for EJB deployment.

 

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 will fail.

 

Oracle BLOB Type not supported in EJB 2.x deployment

If the mapped table includes an Oracle BLOB column, an exception will be thrown during deployment.

 

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, delete the deployment code first. If you do not delete the deployment code first, the old, generated classes will not be removed and may contain compilation errors. This may also be true if you change the type of your primkey-field using the Edit action on the Beans page. This will automatically change the key class to the type specified or a new compound key will be created if a primkey-field is no longer valid.

 

Deploying EJB applications with converters and composers on WebSphere Application Server v4.0.6

Deploying on WebSphere Application Server v4.0.7

The following converters or composers are either missing or out of date in WebSphere Application Server v4.0.6 (but updated in WebSphere Application Server v4.0.7):

If you are using converters and composers in your EJB to RDB mapping, and if you are deploying on WebSphere Application Server v4.0.6:

Workaround: Copy the vaprt.jar from the j2ee.core plug-in's runtime directory to your WebSphere Application Server run time lib directory.

 

Migration

If you want to migrate an EJB 1.0 JAR file to your product and have modified the existing generated deployment code to get it to work with a specific database vendor (for example, changing the case of column names to mixed case), that change will not be preserved when you redeploy the JAR file using the product.

If you originally used VisualAge for Java to specify a mapping and generate the deployment code, then you will need to export the EJB project from VisualAge for Java as an EJB 1.1 JAR file. This will preserve your mapping metadata and the case of table and column names.

 

Related concepts

EJB deployment tool

 

Related tasks

Generating EJB deployment code from the workbench
Generating EJB deployment code from the command line