Repository access through Business Central broken after deleting a repository in BRMS cluster

Solution Unverified - Updated -


  • Red Hat JBoss BRMS
    • 6.0.2


  • I have a cluster of 2 servers, which share the repositories, so changes through each instance of Biz Central in the cluster are visible to all instances. At first it worked fine. But now I get an error message box displayed with the following text:
Unable to complete your request. The following exception occurred: java.lang.IllegalArgumentException:Parameter named 'resource' is not instance of clazz 'RuntimeResource'!.

This error occurs any time I log in, and when navigating from the home page to the Project Authoring page. After I click OK, on the error message box, the page loads, but the explorer pane on the left is blank, so I don't have visibility of any repositories or project info.


The issue is filed as a BZ ( and will likely be fixed in BRMS 6.1.0.

As an interim workaround, please follow the steps:
- Delete a OrganizationUnit in problem ([Administration]->[Manage Organizational Units]-> "Delete" button in Organizational Unit Manager)
- Create a OrganizationUnit again with the same name ("Add" button in Organizational Unit Manager)
- Associate repositories for the OrganizationUnit (Use list-box in Organizational Unit Manager)

Root Cause

The issue is filed as a BZ ( and will likely be fixed in BRMS 6.1.0.

This issue happens in the sequence:

  1. Delete a repository in a cluster environment
  2. BRMS doesn't correctly de-associate the delete repository from an OrganizationalUnit
  3. Next login after BRMS reboot loads the wrong OrganizationalUnit state
  4. Result in the IllegalArgumentException

Diagnostic Steps

  • Enable DEBUG level log for 'org.jboss.errai'. You will see DEBUG level stack trace.
08:44:06,191 DEBUG [] (http-/ RPC endpoint threw exception:: java.lang.IllegalArgumentException: Parameter named 'resource' is not instance of clazz 'RuntimeResource'!
        at [uberfire-security-api-0.3.3-redhat-4.jar:0.3.3-redhat-4]
        at [uberfire-security-api-0.3.3-redhat-4.jar:0.3.3-redhat-4]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) [rt.jar:1.7.0_60]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) [rt.jar:1.7.0_60]
        at java.lang.reflect.Method.invoke(Unknown Source) [rt.jar:1.7.0_60]
        at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke( [weld-core-1.1.13.Final-redhat-1.jar:1.1.13.Final-redhat-1]
        at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke( [weld-core-1.1.13.Final-redhat-1.jar:1.1.13.Final-redhat-1]
        at org.jboss.weld.proxies.AuthorizationManager$1418655305$Proxy$_$$_WeldClientProxy.authorize(AuthorizationManager$1418655305$Proxy$_$$ [weld-core-1.1.13.Final-redhat-1.jar:]
        at org.kie.workbench.common.screens.explorer.backend.server.ExplorerServiceImpl.getRepositories( [kie-wb-common-project-explorer-backend-6.0.3-redhat-4.jar:6.0.3-redhat-4]
        at org.kie.workbench.common.screens.explorer.backend.server.ExplorerServiceImpl.getContent( [kie-wb-common-project-explorer-backend-6.0.3-redhat-4.jar:6.0.3-redhat-4]
        at org.kie.workbench.common.screens.explorer.backend.server.ExplorerServiceImpl$Proxy$_$$_WeldClientProxy.getContent(ExplorerServiceImpl$Proxy$_$$ [kie-wb-common-project-explorer-backend-6.0.3-redhat-4.jar:6.0.3-redhat-4]
  • If the stack trace comes from ExplorerServiceImpl.getRepositories(), the root cause is likely the one described in "Root Cause" section. If not, need further debugging (e.g. apply a debug module to print out 'resouce.getClass()' in RuntimeResourceManager.requiresAuthentication())

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.