You will need to customize the test-bed in order when you want the EJB cells to perform more operations than the ones provided by default or when you want to generate your own call flows.

The following aspects can be customized:

• The number and type of EJBs

• The calling pattern between EJBs

• The CPU and memory load parameters (or indeed other parameters in the case of custom job simulation logic - see below)

• Potential memory leaks (of a custom size)

• Potential exceptions to be raised

• Custom Simulation logic: you can change the behavior of the test cells. For instance, you can print a message each time an EJB cell has been called, or you can perform database operations as part of the configuration executions.

Building the J2EE test-bed

After you have created your own version of the test-bed, you need to build it (this compiles all the bean cells and creates the deployment archives). To build the J2EE test-bed, just run ant in the directory where you have the build.xml (the root directory of the download archive). Refer to the installation instructions for dependencies.

When building, ignore the error messages (there should be 2) like this: "Unable to locate jboss deployment descriptor". They are due to the current packaging structure that mixes Websphere specific deployment desciptors with JBoss ones. They will not have any effect on your built system.

Changing the number and type of EJBs

All you need to do to add / remove EJBs from the test-bed is to change the deployment descriptor accordingly. AdaptiveCells/J employs a completely declarative model for generating its testbeds, so you never need to worry about writing EJBs.

The deployment information is in the tb1-ejb-jar.xml deployment descriptor. This contains the usual J2EE required fields for EJB deployment and the AdaptiveCells/J required fields. For each deployed EJB cell, there are XML fields corresponding to each configuration (see the description of AdaptiveCells/J for more information on the configurations).

Changing the calling pattern between EJBs and the CPU and memory usage parameters

To be useful, each EJB cell must have at least one configuration and each configuration must contain environment  entries for it's CPU usage (called configXcpu), for it's memory usage (called configXmem) and optionally for it's callees (called configXfirstCalee and configXsecondCalee). 

In addition to setting CPU usage, memory usage and callees, you can configure each EJB to exhibit memory leaks (by setting the configXleak entry) or can raise an exception (by setting the configXexception entry).

When you download AdaptiveCells/J you will receive a working J2EE EAR and you can better understand the format of these configurations in the deployment descriptor.

The calling pattern for each configuration is defined by the configXfirstCalee and configXsecondCalee values defined for that configuration in each EJB (see the description of AdaptiveCells/J for configuration details and the test-bed structure documentation for configuration examples).

Changing the simulation logic executed by the EJB cells

Each test cell executes a job simulation when it is called. Currently, the job implementation called SimpleSimulator emulates CPU load and memory usage corresponding to the deployment descriptor values for the current configuration (the configuration name is received as a call parameter). You can add another job simulation class that implements the interface JobSimulation. Then, in order to have this new class used instead of the SimpleSimulator, you need to update the SimulationFactory class to return the new job simulation type.

More complex behavior can be added by changing the SimulationManager and SimulationConfiguration classes (please see their code for more information on this aspect).