div.collapsecontent{display:block;}

Express (Distributed operating systems), v8.0 > Reference > Command-line utilities > EJB deployment tool > Reference > Limitations of EJB deployment


Run the ejbDeploy command can generate compilation errors for DB2 V9 for z/OS

If we 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.

Here is an example of the complication errors: 

[exec]
[*Error] ejbModule/websphere_deploy/DB2UDBOS390_V9_1/OleEJBBeanInjectorImpl_8ec5a2a7.java(22): The method set(int, Object) in the type List is not applicable for the arguments (int, long)
[exec]
[*Error] ejbModule/websphere_deploy/DB2UDBOS390_V9_1/OleEJBBeanInjectorImpl_8ec5a2a7.java(59): The method set(int, Object) in the type List is not applicable for the arguments (int, long)
[exec]
[*Error] ejbModule/websphere_deploy/DB2UDBOS390_V9_1/OleEJBBeanCacheEntryImpl_8ec5a2a7.java(6): The type OleEJBBeanCacheEntryImpl_8ec5a2a7 must implement the inherited abstract method OleEJBBeanCacheEntry_8ec5a2a7.setOCC_OLEEJB(long)
[exec]
[*Error] ejbModule/websphere_deploy/DB2UDBOS390_V9_1/OleEJBBeanCacheEntryImpl_8ec5a2a7.java(58): The return type is incompatible with OleEJBBeanCacheEntry_8ec5a2a7.getOCC_OLEEJB()
[exec]
[*Error] ejbModule/websphere_deploy/DB2UDBOS390_V9_1/OleEJBBeanCacheEntryImpl_8ec5a2a7.java(80): The return type is incompatible with OleEJBBeanCacheEntry_8ec5a2a7.getOCCColumn()
When generating EJB deployment code using either the Prepare for deployment option from the workbench or the ejbDeploy from a command line, a ConcreteBean class is generated that contains the getOCCColumn method, which is shared by all back ends. The return data type of the getOCCColumn method is typically long: 
/**
  * getOCCColumn
  */
 public long getOCCColumn() {
  return dataCacheEntry.getOCCColumn();
 }
However for the DB2UDBOS390_V9 back ends, when generating the deployment code for the enterprise beans the getOCCColumn method is generated with a java.sql.Timestamp return type: 
/**
  * getOCCColumn
  */
 public java.sql.Timestamp getOCCColumn() {
  return dataCacheEntry.getOCCColumn();
 }
As a result, the getOCCColumn method generated for a DB2UDBOS390_V9 back end cannot be shared with other back ends because the difference in return types.


Resolve the problem:

The DB2UDBOS390_V9 back-end mapping cannot coexist with back-end mappings from other database vendors in the same EJB JAR file, where these back ends have mappings to a collision detection column. Before generating the EJB deployment code, have two separate EJB JAR files, where one contains the DB2UDBOS390_V9 back end and the other contains back ends from the other database vendors.

To separate the back ends:

  1. Use the development workbench, such as Rational Application Developer.

  2. Create a temporary folder under the <EJBProject>/ejbModules/META-INF directory. The temporary folder should be at the same directory-level as the <EJBProject>/ejbModules/META-INF/backends folder. This temporary folder is going to contain the back-end folders you want to separate out of the EJB JAR file, in particular from the META-INF/backends folder. As a result, the back-end mappings in this temporary folder are ignored when generating EJB deployment code and when running the application on the WAS. Only back ends in the META-INF/backends folder is going to generate the deployment code and are active during the run time of the server.

    1. In the Enterprise Explorer view, expand your EJB project and the ejbModule folder.
    2. Right-click the META-INF folder and select New > Folder.

    3. In the New Folder wizard, specify your temporary folder name, such as backends_temp, in the Folder name field and click Finish.

  3. Determine the current back-end ID set in the EJB deployment descriptor editor.

    1. In the Enterprise Explorer view, expand your EJB project, right-click the Deployment Descriptor node and select Open With > Deployment Descriptor Editor.

    2. In the Overview page of the EJB Deployment Descriptor editor, scroll down to the WebSphere Bindings section.

    3. Verify the back-end ID in the Current field under the Backend ID section.

  4. Use the current back-end ID set for your EJB Project to help determine which back-end folders to separate out into the first EJB JAR file:

    • If the current back-end ID is set to DB2UDBOS390_V9, move all the back-end folders under the META-INF/backends folder to under the META-INF/backends_temp folder.

    • If the current back-end ID is set to a database vendor other than DB2UDBOS390_V9, move the DB2UDBOS390_V9 back-end folder under the META-INF/backends folder to under the META-INF/backends_temp folder.

  5. Generate the EJB deployment code in the workbench or from the command line:

    Options Description
    Workbench

    1. In the Enterprise Explorer view, right-click the EJB project and select Java EE > Prepare for Deployment.
    2. Export the EJB JAR file from the workbench, using the EJB Jar Export wizard (select File > Export > EJB > EJB JAR file).

    Command-line

    1. Export the EJB JAR file from the workbench, using the EJB Jar Export wizard (select File > Export > EJB > EJB JAR file).

    2. When generating the deployment code, use this exported EJB JAR file as input into the ejbDeploy command with the -OCCColumn parameter specified.

  6. Change the current back-end ID for the second EJB JAR file:

    • If the current back-end ID in the first EJB JAR file was set to DB2UDBOS390_V9, change the current back-end ID to any other database vendor defined under the META-INF/backends folder

    • If the current back-end ID in the first EJB JAR file was set to another database vendor other than DB2UDBOS390_V9, change the current back-end ID to DB2UDBOS390_V9

  7. We can change the current back-end ID for the second EJB JAR file using the EJB deployment descriptor editor:

    1. In the Enterprise Explorer view, expand your EJB project, right-click the Deployment Descriptor node and select Open With > Deployment Descriptor Editor.

    2. In the Overview page of the EJB Deployment Descriptor editor, scroll down to the WebSphere Bindings section.
    3. Change the back-end ID in the Current field under the Backend ID section.

  8. Use the current back-end ID set for your EJB Project to help determine which back-end folders to separate out into the second EJB JAR file:

    • If the current back-end ID is set to DB2UDBOS390_V9, move all the back-end folders under the META-INF/backends folder to under the META-INF/backends_temp folder; and then move the DB2UDBOS390_V9 back-end folder under the META-INF/backends_temp folder back into the META-INF/backends folder.

    • If the current back-end ID is set to a database vendor other than DB2UDBOS390_V9, move all the other back-end folders under the META-INF/backends_temp folder back into the META-INF/backends folder; and then move the DB2UDBOS390_V9 back-end folder under the META-INF/backends folder to under the META-INF/backends_temp folder.

  9. Repeat step #5 for generating the EJB deployment code using the second EJB JAR file.


Related


The ejbdeploy command
Feedback

+

Search Tips   |   Advanced Search