summaryrefslogtreecommitdiffstats
path: root/bpmn/MSOInfrastructureBPMN/src/test/resources/__files/DeleteVfModuleCallbackResponse.xml
diff options
context:
space:
mode:
authorRob Daugherty <rd472p@att.com>2017-11-08 18:35:49 -0500
committerRob Daugherty <rd472p@att.com>2017-11-08 21:27:10 -0500
commitd750eabf5de2423f0a7c89ffbfbcc0d65bb4623e (patch)
tree2bea22d58ac6c5844e58a71487ee27b3c64ee832 /bpmn/MSOInfrastructureBPMN/src/test/resources/__files/DeleteVfModuleCallbackResponse.xml
parent3935e84e0306183450fc080a09fcc1d13ced345e (diff)
Clean up Process Engine selection logic
Several failed attempts to split the BPMN application into multiple applications with separate camunda process engines have left a mess of confusing classes and process engine definitions. In the Amsterdam release, there should be only one BPMN application war. This is MSOInfrastructureBPMN. MSOCommonBPMN should not be deployed as a separate application. Its classes are compiled into a jar and this is included inside MSOInfrastructureBPMN. The MSOInfrastructureBPMN application should use the "default" process engine. WorkflowAsyncInfrastructureResource and MSOCommonApplication classes are not needed. Issue: SO-322 Change-Id: Ifdb3b33541346b561a16361d1aa791e8342a34fa Signed-off-by: Rob Daugherty <rd472p@att.com>
Diffstat (limited to 'bpmn/MSOInfrastructureBPMN/src/test/resources/__files/DeleteVfModuleCallbackResponse.xml')
0 files changed, 0 insertions, 0 deletions