Red Hat Bugzilla – Bug 1316974
OSGi: Default MVEL UserGroupCallback does not work in OSGi
Last modified: 2016-04-25 08:19:42 EDT
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:
The debugger reveals that the class context is:
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):
Steps to Reproduce:
1. look at  in KieBlueprintjBPMPersistenceKarafIntegrationTest from PR https://github.com/droolsjbpm/droolsjbpm-integration/pull/315
2. comment out the line 
3. put a breakpoint at  (creating the RuntimeManager)
4. uncomment  (enable Karaf debugging)
5. run 'mvn clean test -Dtest=KieBlueprintjBPMPersistenceKarafIntegrationTest'
6. attach debugger and setp over to see the error
MvelUserGroupCallback fails to initialize in OSGi environment.
MvelUserGroupCallback initializes successfully.
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?
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?
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 .
Doc issue has been fixed (see linked JIRA).