Gen 8.6 EJB Web Services CASCADE.jar deployment for multiple ear files per model and multiple models

Products

• Gen

Issue/Introduction

For a multiple model architecture, where each model has some set of different Entity Types and Relations.
When assembling a Server Manager per ear file does the RI Triggers CASCADE.jar need to be included in each ear file?
Is it possible to use WebSphere Application Server CLASSPATH and place the CASCADE.jar from different models into different absolute paths in that CLASSPATH? How to ensure that the applications from one model use their CASCADE.jar file and not the one generated from a different model?

Environment

Release : 8.6
Component : CA Gen Enterprise Java Beans

Resolution

It is the RI Trigger class files within each CASCADE.jar file that will be called by the action block generated code, so the uniqueness of those trigger class file names in the deployed environment needs to be considered.
An RI Trigger class file has a name based on the corresponding automatically generated ACBLKTD object name in the model and that object name has format "Ennnnnnn" or "Fnnnnnnn". Those object names could potentially be the same across different applications from different models.

1. So even if separate CASCADE.jar files were deployed to different WebSphere Application Server CLASSPATH directories the order of those jar files in the CLASSPATH might cause an incorrect class to be used if a trigger (ACBLKTD) name happens to be the same across different deployed applications/models.
The only option to ensure unique trigger names across all models in an Encyclopedia is to use the Rename Object option for object type IMPLEMENTATION LOGIC and set each trigger to have a unique name:
CA Gen 8.6 > Encyclopedia > Host Encyclopedia > Using the Host Encyclopedia > Manage Models in the Host Encyclopedia > Delete or Rename Objects
CA Gen 8.6 > Encyclopedia > Client Server Encyclopedia > Use the Client Server Encyclopedia > Manage Models > Work With Objects
If that unique naming process is not feasible then for each model generation, when assembling either a single Server Manager per ear file or multiple Server Managers per ear file the CASCADE.jar file always needs to be deployed within the ear file to ensure the integrity of use.

2. Instead of being concerned with WebSphere CLASSPATH directories, a more optimum solution would be to create a WebSphere shared library for each CASCADE.jar file. When creating the shared library in WebSphere a unique name/label will need to be given for each CASCADE.jar file which can keep its original file name as long as they all reside in different directories.
Then at application install time the correct CASCADE shared library needs to be associated with the application ("Detailed Path" install steps required).