Description of problem: If RuntimeManagerFactory [1] initialization fails, any subsequent call to Factory.get() will fail. However, in OSGi environment, KIE-API bundle might have been initialized before jBPM Runtime manager bundle was installed - in that case, even if you installed jbpm feature later, RuntimeManager still fails to initialize. The only way to make KIE-API reinitialize RuntimeManager is to restart KIE-API bundle. When debugging [1], it turned out that property Factory.initialized is set to true even when the initialization fails (even if it was for a different ClassLoader parameter) and there is no way to initialize it again (except restarting the bundle). [1] https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/master/kie-api/src/main/java/org/kie/api/runtime/manager/RuntimeManagerFactory.java#L104 Version-Release number of selected component (if applicable): BRMS 6.2.1 Fuse 6.2.1 How reproducible: always Steps to Reproduce: 1. install jbpm bundle 2. attempt to initialize RuntimeManagerFactory in your app bundle I will provide a unit test reproducer later. Actual results: RuntimeManagerFactory fails to initialize and RuntimeManagerFactory.Factory.get() returns null. Expected results: RuntimeManagerFactory reattempts to initialize.
I would not mind if this behaviour occurred strictly when you install 'kie-api' and then later 'jbpm' features. What puzzles me is that the problem occurs also when you install just 'jbpm' feature.
Marek, so this happens when you install jbpm feature without kie api? Not sure I fully understood the problem... We could provide reset method on RuntimeManagerFactory which would put it back to initial state. Would this be valid solution? I'd like to avoid any more advanced logic as that could lead to unexpected runtime consequences. P.S. is there anywhere that reproducer or wasn't it yet created?
Maciej, sorry for not having this described in more detail. The test case (org.drools.karaf.itest.RuntimeManagerFeatureKarafIntegrationTest) can be found in [1], sorry for the delay with the reproducer. It was also caused by the fact that I was unable to reproduce the original behaviour - let me summarize the problem: 1. user installs drools-module feature - it includes kie-api, drools, but not jBPM, 2. user attempts to obtain a jBPM service from the KIE-API, e.g. RuntimeManagerFactory using "RuntimeManagerFactory.Factory.get()", which returns null (no jBPM installed, so this behaves as expected), 3. user installs jbpm feature, 4. user calls "RuntimeManagerFactory.Factory.get()" again, which should now succeed, but it does not; instead, it throws the following exception: java.lang.RuntimeException: RuntimeManagerFactory was not initialized, see previous errors Unfortunately, I was unable to reproduce the original problem I had when I installed jbpm feature only and encountered this exception - maybe I had made a mistake somewhere at that time (or there is a nasty race condition which I was unable to reproduce now). Hope this makes it clear, sorry for not being specific enough in the initial description. [1] https://github.com/droolsjbpm/droolsjbpm-integration/pull/357
I believe we are already using very similar approach in Drools, namely for ProcessBuilderFactory and ProcessRuntimeFactory. See https://github.com/droolsjbpm/drools/commit/b28fd0a2b and https://github.com/droolsjbpm/jbpm/commit/da31bb30a90a The factories are being forcefully re-initialized from jBPM Activators.
Thanks Petr, I followed similar approach as in mentioned change on drools/jbpm droolsjbpm-knowledge master https://github.com/droolsjbpm/droolsjbpm-knowledge/commit/6ddcadd9eb0b7fd85670eb08b7d9d7fbaa5504f5 6.4.x https://github.com/droolsjbpm/droolsjbpm-knowledge/commit/4add4634d9f6725d27635764edf0911485f0755a jbpm master https://github.com/droolsjbpm/jbpm/commit/e42ed0d4a04f0225cce0aca55234fb4da3ac2f05 6.4.x https://github.com/droolsjbpm/jbpm/commit/fee656606d29e4a9025bc63cf9e11329d5128eac droolsjbpm-integration master https://github.com/droolsjbpm/droolsjbpm-integration/commit/738af66181b80be6addd6c32d18902437cc7cdda 6.4.x https://github.com/droolsjbpm/droolsjbpm-integration/commit/73c928d6b4d05d20aa20e989dd19b1d45b428810
Verified in BRMS 6.3.0 ER2.