Description of problem: When calling RuntimeManagerFactory.newSingletonRuntimeManager() with the default MVELUserGroupCallback in OSGi, it fails with no specific exception. Using debugger, you can see that an InvocationTargetException was thrown with target CompileException which cannot be evaluated to string due to: Method threw 'java.lang.StringIndexOutOfBoundsException' exception. Cannot evaluate org.mvel2.CompileException.toString() The cause of the CompileException is the following: java.lang.ClassNotFoundException: org.jbpm.services.task.impl.model.UserImpl The debugger reveals that the class context is: class org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer class org.mvel2.ast.NewObjectNode class org.mvel2.compiler.ExecutableAccessor ... class org.mvel2.MVELRuntime ... class org.drools.core.util.MVELSafeHelper$RawMVELEvaluator class org.jbpm.services.task.utils.MVELUtils class org.jbpm.services.task.identity.MvelUserGroupCallbackImpl class org.jbpm.services.task.HumanTaskConfigurator class org.jbpm.runtime.manager.impl.factory.LocalTaskServiceFactory class org.jbpm.runtime.manager.impl.SingletonRuntimeManager class org.jbpm.runtime.manager.impl.RuntimeManagerFactoryImpl ... class org.drools.karaf.itest.beans.ProcessWithPersistenceBean I have tried to add the not found class' package to Import-Package header of the bundle, but it did not help. I understand that MvelUserGroupCallback might not be used in production, so I am setting severity to medium - if that assumption is not true, feel free to raise severity to high. In case this was not fixable with reasonable effort and MvelUserGroupCallback was really not intended for production use, we could document this as a known issue. Version-Release number of selected component (if applicable): BRMS 6.2.2 Fuse 6.2.1 How reproducible: always Steps to Reproduce: 1. look at [1] in KieBlueprintjBPMPersistenceKarafIntegrationTest from PR https://github.com/droolsjbpm/droolsjbpm-integration/pull/315 2. comment out the line [1] 3. put a breakpoint at [2] (creating the RuntimeManager) 4. uncomment [3] (enable Karaf debugging) 5. run 'mvn clean test -Dtest=KieBlueprintjBPMPersistenceKarafIntegrationTest' 6. attach debugger and setp over to see the error [1] https://github.com/droolsjbpm/droolsjbpm-integration/pull/315/files#diff-55f7600103b4324558f5c4e620ca577cR76 [2] https://github.com/droolsjbpm/droolsjbpm-integration/pull/315/files#diff-55f7600103b4324558f5c4e620ca577cR51 [3] https://github.com/droolsjbpm/droolsjbpm-integration/pull/315/files#diff-c4e2df544edb849ffb43b2b5bfdf87b0R86 Actual results: MvelUserGroupCallback fails to initialize in OSGi environment. Expected results: MvelUserGroupCallback initializes successfully.
Marek, MVELUserGroupCallback is sort of leftover from v5 and used only for tests as there were majority of tests relying on it. It should never be used in production code and it might be sometimes used by default to avoid NPEs So I opt at closing as won't fix - wdyt?
Maciej, thanks for explanation, I agree with leaving this as it is, I would just ask docs team to document this specifically for OSGi environment, as users trying to experiment with RuntimeManager might spend considerable time trying to find the source of the problem (since MVELUserGroupCallback is used by default). Tomas, would you prefer a separate BZ or BXMS-DOC JIRA?
Hi, Marek, If you'll be creating a separate issue, please make it a JIRA. Thanks. If not, I think there's a process involving the requires_doc_text flag that allows us to keep track of known issues. I'll find out what it is.
Created BXMS-DOC JIRA [1]. [1] https://issues.jboss.org/browse/BXMSDOC-242
Doc issue has been fixed (see linked JIRA).