1.0 Introduction
2.0 Supported software and specifications
3.0 Known problems
3.1 Refresh problems
3.2 Meet-in-the-middle mapping hints and restrictions
3.3 Drag and drop support in the Mapping editor
3.4 Deleting tables and schemas in the Navigator view of the J2EE perspective
3.5 Optimistic predicates for 1.1 CMP Entity beans
3.6 Inheritance hints and restrictions
3.7 Referencing runtime JAR files at development time
3.8 Do not map composed types across multiple tables
3.9 Deleting a CMP entity does not remove mapping entry
3.10 EJB QL limitations
3.11 Validation for EJB references is not automatic
3.12 Arabic names not supported for Java beans and files
3.13 Query generation limitations
3.14 Problem editing local-ejb-ref link
3.15 Errors in task list after deploying EJB 2.0 relationships
3.16 Specialized ejbCreate missing for non-null foreign key columns
3.17 Limitation of Source page cmp-field changes using inheritance
3.18 EJB deployment code not deleted when changing a bean class
3.19 Unknown primary key is not supported
3.20 Changing the primary key class for a 1.1 CMP with relationships causes compilation errors
3.21 Reflection errors when updating from CVS Repository
3.22 Deleting a FIND query from Outline view
3.23 Source page and EJB inheritance
3.24 EJB QL queries are not generated properly for Many to Many relationships in an inheritance structure
3.25 SQL Server mapping problem with FLOAT datatype
3.26 Linux: Connection problems when running a 1.1 CMP bean against DB2 on a WebSphere Application Server V4 (Unit Test Environment)
3.27 May need to generate deployed code when enterprise beans from another project are used
3.28 Support for mapping enterprise beans to foreign keys and primary keys
3.29 Restriction for inheritance and secondary table mapping
3.30 Cleaning up access beans when migrating beans from EJB 1.1 to EJB 2.0
3.31 Deploying EJB applications with converters and composers on WebSphere Application Server v4.0.6
3.32 Migrating EJB projects that contain binary classes
3.33 Bottom-up mapping implementation for views
The EJB tools provide a specialized environment that you can use to develop enterprise beans. The EJB tools consist of the following entities:
- A J2EE perspective.
- Tools and wizards for creating, importing, and exporting enterprise beans.
- Access bean creation wizard.
- Tools for building data persistence into enterprise beans.
- Tools for generating deployment code.
This readme file describes the known problems, limitations, and workarounds that are associated with the EJB tools.
The -dbvendor option of the ejbdeploy command (EJB deployment tool) now supports the following values (corresponding to the databases supported):
but no longer supports these values:
- DB2UDB_V72 (DB2 for Windows, V7.2) -- This supercedes the previously supported DB2UDBWIN_V72.
- DB2UDB_V81 (DB2 for Windows, V8.1) -- This supercedes the previously supported DB2UDBWIN_V81.
- SQL92 (Generic SQL 92)
- SQL99 (Generic SQL 99)
- MYSQL_V323 (MySQL, V3.23)
- DB2UDBAS400_V4 (DB2 for AS/400, V4) -- This is superceded by DB2UDBISERIES (DB2 for ISeries).
- DB2UDBAS400_V5 (DB2 for AS/400, V5) -- This is superceded by DB2UDBISERIES (DB2 for ISeries).
- INFORMIX_V92 (Informix Dynamic Server.2000, V9.2)
- SYBASE_V1192 (Sybase Adaptive Server Enterprise, V11.9.2)
- DB2UDBWIN_V71 (DB2 for Windows, V7.1)
- DB2UDBWIN_V72 (DB2 for Windows, V7.2) -- This is superceded by DB2UDB_V72.
- DB2UDBWIN_V81 (DB2 for Windows, V8.1) -- This is superceded by DB2UDB_V81.
If files or resources in the workbench seem to be out of synch or an unexpected failure occurs, for example, editors and views do not reflect current deployment descriptor settings, closing and re-opening the project from the Project menu may fix the problem.
- Match by name - will only handle exact matches. If you generated your schema using the WebSphere Application Server Version 3.5 compatible switch or imported a WebSphere Application Server Version 3.5 JAR, your table names are appended with 'tbl' and will not be recognized.
- Inheritance - the children beans will not be mapped if they do not have fields of their own. You need to map these to the parent table by hand.
- java.util.Date is not supported in 1.1 CMP field mapping
- If using a composer in a mapping, Generate the map, save it,close and re-open the project, then deploy.
Drag and drop is only supported in the "direction" of the map. For example, if the map was created from a "Top-down" operation, then dragging an enterprise bean onto a database is permitted. The following drag and drop operations are allowed:
- Dragging an enterprise bean onto a table creates a map between the two.
- Dragging a bean onto a DB creates a corresponding table and columns, and maps it to the bean and attributes.
If a table needs to be deleted, use the Data perspective or J2EE Hierarchy view of the J2EE perspective, then all dependent links will also be removed. Normally you should not use the Navigator or the J2EE Navigator for deleting J2EE resources because dependencies will not be updated.
In WSAD 5.0, we added the capability for the bean developer to identify the attributes to be used for the overqualified update. EJB jar files created using earlier releases of WSAD do not contain this specification for 1.1 CMP entity beans. However, when deployed using WSAD 5.1, the previous semantics are supported. Specifically, in the absence of a list of attributes, all the available predicates are used. Note that 2.0 CMP entity beans are treated differently. If no attributes are selected as predicates, then none are added to the overqualified update.
- Do not use BLOB types in a root-leaf inheritance structure if you are using Oracle as your database.
- Root-leaf inheritance mapping cannot be supported for the MySQL, InstantDB, SQL92, and SQL99 databases. They do not support the SQL set operators required for the complex queries used for a root-leaf mapping. To test against these databases, you will need to use single-table mapping.
- Mapping CMP fields to Not-Null columns is not supported in inherited beans. Optimistic predicates can only be set on CMP fields from the root bean.
If you need to compile against JAR files visible to the Websphere Application Server runtime (for example, rt.jar, xerces.jar, and so on), then as a general rule, you should add those JAR files for the respective runtime installation using the predefined classpath variables. For example, you should use the WAS_PLUGINDIR classpath variable for the WebSphere Application Server v4.0 server JAR files and the WAS_50_PLUGINDIR classpath variable for the WebSphere Application Server v5.0 server JAR files.
The Mapping editor allows you to map a composed type to multiple columns in different tables. This will cause errors in the generation of deployment code. Ensure that all columns within the composed type mapping belong to the same table.
When a CMP entity is deleted, the corresponding maps that this bean references will not have their mappings removed. When the Mapping editor is opened on these files after an entity is deleted, the mappings will be removed. This is expected behavior. You will need to open the Mapping editor prior to generating deployment code.
- EJB QL queries involving enterprise beans with keys made up of relationships to other enterprise beans will appear as invalid and cause errors at deployment time. This is a known defect.
- The IBM EJB QL support extends the EJB 2.0 specification in various ways, including relaxing some restrictions, adding support for more DB2 functions, and so on. If portability across various vendor databases or EJB deployment tools is a concern, then care should be taken to write all EJB QL queries strictly according to Chapter 11 in the EJB 2.0 specification.
Validation for EJB local references, EJB references, and resource references does not happen automatically when changes are made to these references. The EAR validator needs to be explicitly triggered for validation to be completed on these references.
Do not use Arabic names for Java files, Java beans, or access beans. Do not use Arabic names when working through the MiniBank example.
- Pre-loading across m:n relationships will result in the generation of bad SQL. This is a known limitation that may be addressed in the future.
- Pre-loading across self referencing relationships will cause bad SQL to be generated.
- Relationships between parent and children enterprise beans within the same inheritance hierarchy that are not well-defined should be avoided.
Attempting to edit the link of a local-ejb-ref in the "References" page of the EJB Deployment Descriptor Editor with the "Browse" button will not allow selection of a target bean that does not have a remote interface. The workaround is to delete the reference and recreate it.
If you remove an EJB 2.0 relationship, and regenerate deployment code, you may see invalid errors in the task list. The workaround is to first remove the deployment code for the beans before regenerating it.
Occasionally, invalid errors in the task list are also seen after adding an EJB 2.0 relationship and regenerating deployment code. In this case, simply regenerate again to remove the errors.
If you do a bottom-up mapping on a schema with a foreign key whose columns are non null, then a specialized ejbCreate() method needs to be created with the client interface type of a role added to the signature. This is not automatically done by the bottom-up mapping.
In order to support the EJB 1.1 and 2.0 specifications, we are required to create a matching cmp-field for each subtype bean within an EJB inheritance structure. If you open the EJB Deployment Descriptor editor and modify the name of one of these fields on the Source page, the corresponding name change will not be made on the cmp-fields that were created on the subtype beans to satisfy the EJB specifications. The workaround is to use the Edit action from the Beans page to change the name.
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 existing bean class, interfaces, and key classes.
If you generated the deployment code for a bean and you want to change one of these classes, you must 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.
The EJB tool currently does not support the Unknown primary key definition described by the EJB 2.0 specification. The workaround is to define a specific primary key class.
In order to support 1.1 CMP relationships, Link classes are created. These Link classes require the knowledge of the beans primary key classes. If you change the primary key class for a 1.1 CMP that is involved in relationships, the generated Link classes will still contain references to the old primary key class. The workaround is to manually update the Link classes. There should only be two occurrences where the change is necessary.
If, after you update an EJB project from a CVS Repository, the Tasks displays errors mentioning classes or interfaces not being reflected, try rebuilding the EJB project to make the errors go away.
The error might look like this: "CHKJ2802E: ejb-class class test.SessionBean, or one of its supertypes, cannot be reflected. Check the classpath."
Deleting a FIND query from a 2.0 CMP bean containing a local interface from the Outline view fails to remove the method declaration from the local home interface. The workaround is to use the remove button in the Queries section of the EJB Deployment Descriptor editor.
If you are modifying the shape of CMP beans in an inheritance hierarchy, you should use the design pages of the EJB deployment descriptor editor, not the Source page. For example, if you want to add or remove CMP fields, or change the prim-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.
In this scenario, you have an EJB inheritance structure defined (either root/leaf or single table inheritance) and there is a Many to Many relationship to an EJB bean within this structure. With this case, any EJB QL queries that are defined for these beans will have incorrect JOIN statements
Here is an example of the structure.
Customer <---- m:m ----> Account
|
|
------inherit------
nbsp; | |
Checking Savings
If your CMP bean has been mapped to an SQL Server database, then a field of type float needs to be mapped to a column of type FLOAT, not REAL.
You may encounter connection problems when you run a 1.1 CMP bean against DB2 in the Unit Test Environment of WebSphere Application Server V4.
Workaround: Set loopback for your database.
For example, if your database is named MyDB, your hostname is LHOST, and your database service port number is 50000, issue the following commands:
db2 catalog TCPIP node RHOST remote LHOST server 50000
db2 catalog database MyDB as MyDBAlias
db2 uncatalog db MyDB
db2 catalog database MyDBAlias as MyDB at node RHOSTTo verify if this works, issue the command: db2 connect to MyDB user xxx
where xxx is your password.
If an enterprise bean in an EJB project uses the home or remote interface of a second enterprise bean in another project (for example, if it has a method which takes the remote interface of the second enterprise bean as a parameter), you need to generate deployed code for both projects if you change the home or remote interface of the second enterprise bean.
This is to ensure that the RMIC-generated classes for the second enterprise bean are up-to-date in both projects.
When you are mapping an enterprise bean to a database table, there are several restrictions involving foreign keys and primary keys:
- If the table has multiple foreign keys that contain multiple columns, the foreign keys cannot overlap each other if both foreign keys are used in a mapping to two different EJB relationships. For example, if ForeignKey1 contains ColumnA and ColumnB, ForeignKey2 can contain ColumnC and ColumnD, but cannot contain ColumnB and ColumnC. If ForeignKey2 contains ColumnB and ColumnC, the two foreign keys would overlap each other.
- If the table has a multi-column primary key and one or more foreign keys that share those columns, the foreign keys must either contain the exact same column(s) as the primary key or contain columns entirely outside the primary key. For example, if PrimaryKey1 contains ColumnA and ColumnB, ForeignKey1 can contain ColumnA and ColumnB or ColumnC and ColumnD, but it cannot contain ColumnB and ColumnC. In the case of multiple foreign keys, each foreign key must meet this requirement.
If you are using the root-leaf approach to mapping inheritance or are using secondary maps with multiple tables, you should remove the foreign-key constraints from the database to avoid referential integrity ordering issues (SQL statements executed out of order).
Because access beans are not supported for enterprise beans that only have local client views, you may 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.
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, you need to apply an eFix to your WebSphere Application Server. The WAS eFix updates the vaprt.jar file.
The WAS eFix is PQ76109.
In WebSphere Studio Application Developer v5.1, the vaprt.jar file, which houses default converters and composers, has changed. Due to these changes, the vaprt.jar file in WebSphere Application Server v4.0.6 needs to be updated. The WAS eFix synchronizes this vaprt.jar file.
An alternative workaround to the eFix is to copy the vaprt.jar from the j2ee.core plugin runtime directory to your WAS runtime lib directory. The following converters or composers are out of date in WAS v4.0.6 without the eFix:
VapBigDecimalToBooleanConverter VapBigDecimalToDoubleConverter VapBigDecimalToFloatConverter VapBigDecimalToIntegerConverter VapBigDecimalToLongConverter VapBigDecimalToShortConverter VapTimestampToUtilDateConverter NameComposer VapUSPhoneNumberComposer
When you use the Migration wizard to migrate an EJB project that contains one or more binary Java classes (.class files), the migration will successfully migrate the project components that contain source Java files (.java files), but it will not migrate the binary classes. You will need to manually fix any errors.
When you do a bottom-up mapping (generate enterprise beans based on existing tables), by default the wizard does not generate beans for underlying tables for views. However, because relationships need to be created for foreign keys, the wizard automatically creates a bean for any table that has any foreign keys or whose primary key is pointed to by any foreign keys from other tables. If you clear the Do not create beans for underlying tables for views check box, the wizard generates beans for all tables and views in the database schemata.
Return to the main readme file
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved.