TIBCO-BW-ADMIN-500444: Failed to start Application in AppNode [MultiEARAppSpace-Node]. Check the AppNode log files for messages starting with TIBCO-THOR-FRWK, TIBCO-BW-FRWK, or TIBCO-BW-SR-FRWK for details. Application State [StartFailed], reason : TIBCO-THOR-FRWK-500201: Failed to start bundle [CommonXpathExtensions_1.0.0.201509041602 [430]], <CausedBy> The bundle "CommonXpathExtensions_1.0.0.201509041602 [430]" could not be resolved. Reason: Another singleton version selected: CommonXpathExtensions_1.0.0.201509161627, Another singleton version selected: CommonXpathExtensions_1.0.0.201509161627

The custom path library function is configured as singleton, which causes the issue. This singleton feature enforces the runtime to have one instance of that plugin running. When the first application is started in the node, it loads the custom xpath function bundle for the first time. When application two is started, due to the dependency configuration, it tries to load the same and fails. This is expected behavior.

There are few workarounds:

1) Disable the singleton. The plugin will show an error but you can still deploy it. During the runtime, both applications will be able to load their own instances. The risk here is that the same plugin will be loaded twice and Eclipse will not be able to provide a common extension point.

2) If the two services (e.g. testCustomXPath_moduleA and testCustomXPath_moduleB) don’t have to be scaled in and out together, we should deploy them in separate AppSpaces.

3) If the two services need to be coupled by their nature, we should consider to merge them into a single service (i.e. putting into the same EAR)

4) Load these singleton modules through a common application module and maintain them there. This application module should be deployed first before deploying any other application. You can safely remove your module dependency from other application modules. They will automatically get the reference (common extension point) during runtime. See the attached sample project (Filename: LoadXpathLibs.module.zip) for more details. However, please note, though this approach can help resolve above singleton issue, it’s less preferable in a Microservice Architecture due to below limitations and should only be used discretionarily.

a. Lack of isolation: In this approach testCustomXPath_moduleA and testCustomXPath_moduleB both depend on LoadXpathLibs so that users have to manage their deployment and startup sequence; if not, during appNode restart, testCustomXPath_moduleA and testCustomXPath_moduleB may fail to start if the platform tries to start them before LoadXpathLibs. Normally, users using this approach will have to create some scripts to make sure LoadXpathLibs is started first and/or start testCustomXPath_moduleA and testCustomXPath_moduleB one more time when they are failed to start during appNode restart.

b. Lack of portability: Since testCustomXPath_moduleA and testCustomXPath_moduleB don’t have module dependency on the custom XPath provider (LoadXpathLibs),  deploying them to Cloud (TCI) or Containers(BWCE).  w/o refactoring could fail.  

See the attached sample project (Filename: LoadXpathLibs.module.zip).