This BZ is related to the following BZs:

https://bugzilla.redhat.com/show_bug.cgi?id=896634
https://bugzilla.redhat.com/show_bug.cgi?id=896640
https://bugzilla.redhat.com/show_bug.cgi?id=902888

The customer is unhappy with the solution provided in the above.  They wish to sub-class EsbActionHandler and manipulate variables individually.  

The customer describes how the did it in 4.3, but not in 5.x:
------------------------------------------------------------------------------
Here is the code from the 4.3.0 CP05 version of the EsbActionHandler:

protected EPR createReplyTo(String esbToJBpmXml, Boolean globalProcessScope, ExecutionContext executionContext)
    {
        EPR replyTo = new LogicalEPR(ServiceInvoker.INTERNAL_SERVICE_CATEGORY, JBpmCallback.JBPM_CALL_BACK_SERVICE_NAME);
        PortReference portReference = replyTo.getAddr();
        if (esbToJBpmXml!=null) {
            portReference.addExtension(Constants.ESB_TO_BPM_VARS_TAG, esbToJBpmXml);
        }
        if (globalProcessScope!=null) {
            portReference.addExtension(Constants.PROCESS_SCOPE_ATTR, globalProcessScope.toString());
        }
...

and here is the code from the 5.3.0 version of the same class:

protected EPR createReplyTo(String esbToJBpmXml, Boolean globalProcessScope, ExecutionContext executionContext)
    {
        EPR replyTo = new LogicalEPR(ServiceInvoker.INTERNAL_SERVICE_CATEGORY, JBpmCallback.JBPM_CALL_BACK_SERVICE_NAME);
        PortReference portReference = replyTo.getAddr();
        if (globalProcessScope!=null) {
            portReference.addExtension(Constants.PROCESS_SCOPE_ATTR, globalProcessScope.toString());
        }
--------------------------------------------------------------------------

The customer's specific complaints about the fix provided by the above BZs:

****************************************************************
Concerning the mapping of variables, I think that it worth a patch as only "half the job" has been done. Effectively being able to set variables mapping during the execution of the action is really useful and may be mandatory depending on the process. Here are some of the issues the current solution may cause:

- really overloading our process definitions as all the possible variables must be defined within it and due to that, they are a lot less readable. In addition to that, the size of the message/executing context will remain bigger and will take more space in the  JBPM or ESB database. This could cause issues in several of our customers having a lot of processes generated on a regular basis.

- introducing more human error possibilities as no default variables mapping may be defined through a default abstract action behavior.

- giving a lot less flexibility.

******************************************************************


Please consider, look for another way to restore the functionality the customer desires.

Thank you,

Rick