Bug 1316974 - OSGi: Default MVEL UserGroupCallback does not work in OSGi
OSGi: Default MVEL UserGroupCallback does not work in OSGi
Status: NEW
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: jBPM Core (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Maciej Swiderski
Marek Winkler
Tomas Radej
Depends On:
  Show dependency treegraph
Reported: 2016-03-11 10:17 EST by Marek Winkler
Modified: 2016-04-25 08:19 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Marek Winkler 2016-03-11 10:17:19 EST
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:

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.
Comment 1 Maciej Swiderski 2016-03-16 13:35:48 EDT

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?
Comment 2 Marek Winkler 2016-03-16 16:03:19 EDT

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?
Comment 3 Tomas Radej 2016-03-17 05:06:39 EDT
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.
Comment 4 Marek Winkler 2016-03-17 05:39:44 EDT
Created BXMS-DOC JIRA [1].

[1] https://issues.jboss.org/browse/BXMSDOC-242
Comment 5 Tomas Radej 2016-04-25 08:19:42 EDT
Doc issue has been fixed (see linked JIRA).

Note You need to log in before you can comment on or make changes to this bug.