Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-3721

The "remote" run mode for KIM (and other Rice modules?) does not allow proper consumption of services from the bus

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0.2
    • Component/s: Development
    • Labels:
      None
    • Similar issues:
      KULRICE-3428Review all services published from each module and determine which should be exported to the bus under which run modes (local, embedded, remote)
      KULRICE-6683Add a "THIN" client run mode to KEW, KIM, and KSB modules
      KULRICE-4303Document initiator check fails when KIM is run in remote mode
      KULRICE-3950Allow KNS-enabled client applications to run KEW in "remote" mode.
      KULRICE-6919Location module can not be run in REMOTE mode
      KULRICE-4140KimTypeInfoService cannot be accessed by "remote" KIM clients directly
      KULRICE-2721Add switch on KIM Configurer to make run in local or remote modes
      KULRICE-4667Evaluate remote KIM services: analysis & decision
      KULRICE-3785KEWConfigurer is still loading the full KEWSpringBeans.xml file even when in "remote" mode.
      KULRICE-3629The IdentityCacheService is unavailable to Rice Client applications running Kim in embedded run mode
    • Rice Module:
      Rice Core
    • Application Requirement:
      Rice

      Description

      This may be a problem with the other modules of Rice but is definitely a problem with KIM.

      When a KNS client application is running KIM using the "remote" run mode... only the KIM Interface spring beans are loaded. This means that when the locally running "IdentityManagementService" tries to retrieve the standalone server's "IdentityService"... the instance of the service that's exposed to the bus from the standalone server has to be used. The problem is that when the KNS client application uses the KimServiceLocator to retrieve the service, there is no namespaceURI value. So the service exists on the bus in this form:

      {KIM}

      kimIdentityService but the KNS client is attempting to retrieve the service in this form: {}kimIdentityService.

      1. kim_remoting_patch01.txt
        2 kB
        Chad Hagstrom
      2. new_kim_remoting_patch01.txt
        8 kB
        Chad Hagstrom
      3. object_remoting_patch01.txt
        4 kB
        Chad Hagstrom

        Issue Links

          Activity

          Hide
          Peter Giles (Inactive) added a comment -

          Hey Chad, I've now run into an issue simlar to what Travis reported above regarding KIM role type services. In this case, the service isn't found at all since it's a service name that is unique to KFS, contractsAndGrantsResponsibilityRoleTypeService. I set a breakpoint inside KIMServiceLocator at line 68 and poked the namespace in the QName constructor to be null when this service was fetched, and it succeeded. Otherwise, I get an incident report. You can see the top part of the stack trace in the linked issue (KULRICE-3757).

          Show
          Peter Giles (Inactive) added a comment - Hey Chad, I've now run into an issue simlar to what Travis reported above regarding KIM role type services. In this case, the service isn't found at all since it's a service name that is unique to KFS, contractsAndGrantsResponsibilityRoleTypeService. I set a breakpoint inside KIMServiceLocator at line 68 and poked the namespace in the QName constructor to be null when this service was fetched, and it succeeded. Otherwise, I get an incident report. You can see the top part of the stack trace in the linked issue ( KULRICE-3757 ).
          Hide
          Chad Hagstrom added a comment -

          Since it looks like both KC and KFS are relying on the KIMServiceLocator to retrieve services exposed under no namespace or their application namespace, then perhaps we could modify the KIMServiceLocator (and the KEWServiceLocator) so that they only add the module namespaces to Rice's bus-accessible services for those modules; that way, any client-app or non-bus-accessible services can be retrieved under a different (if any) namespace if desired, and then we could roll back the namespace-excluding functionality of the Spring resource loaders to prevent naming conflicts, which should not interfere with the module-name-exposed services since I believe many of Rice's such services are deployed on the bus under the same names as the beans themselves. Such a workaround would be less impacting than the solution mentioned in my previous post, so perhaps this fix would work best for the 1.0KC release. The only downsides I can think of would be a lack of namespacing consistency for our services and that the RemoteResourceServiceLocatorImpl would have to be used to find the services whose bean names match their bus-exposed names and which are additionally exposed under a "KEW" or "KIM" namespace. Any other thoughts on this workaround or on another alternative?

          Show
          Chad Hagstrom added a comment - Since it looks like both KC and KFS are relying on the KIMServiceLocator to retrieve services exposed under no namespace or their application namespace, then perhaps we could modify the KIMServiceLocator (and the KEWServiceLocator) so that they only add the module namespaces to Rice's bus-accessible services for those modules; that way, any client-app or non-bus-accessible services can be retrieved under a different (if any) namespace if desired, and then we could roll back the namespace-excluding functionality of the Spring resource loaders to prevent naming conflicts, which should not interfere with the module-name-exposed services since I believe many of Rice's such services are deployed on the bus under the same names as the beans themselves. Such a workaround would be less impacting than the solution mentioned in my previous post, so perhaps this fix would work best for the 1.0KC release. The only downsides I can think of would be a lack of namespacing consistency for our services and that the RemoteResourceServiceLocatorImpl would have to be used to find the services whose bean names match their bus-exposed names and which are additionally exposed under a "KEW" or "KIM" namespace. Any other thoughts on this workaround or on another alternative?
          Hide
          Travis Schneeberger added a comment -

          Chad - As I expressed in KULRICE-3757 I'm just not sure how much more change we should be doing to rice/kc in order to achieve compatibility. To me it seems like we missed the boat on this one. Maybe we consider this a learning experience and try to do a better job next time. I just don't want to destabilize KC while attempting to make KC's rice compatible with KFS - again this is just my view point.

          As for the issue with our type services and namespaces. I don't think we were ever directly looking up our type services with the KIMServiceLocator. It was the KIM services in rice who were looking up KC's type services. All we (KC) really had control of was what namespace we used to export them under with the KSBExporter. We were forced to export them using the only namespace that allowed the Kim services to find our type services which until recently was an empty namespace.

          Show
          Travis Schneeberger added a comment - Chad - As I expressed in KULRICE-3757 I'm just not sure how much more change we should be doing to rice/kc in order to achieve compatibility. To me it seems like we missed the boat on this one. Maybe we consider this a learning experience and try to do a better job next time. I just don't want to destabilize KC while attempting to make KC's rice compatible with KFS - again this is just my view point. As for the issue with our type services and namespaces. I don't think we were ever directly looking up our type services with the KIMServiceLocator. It was the KIM services in rice who were looking up KC's type services. All we (KC) really had control of was what namespace we used to export them under with the KSBExporter. We were forced to export them using the only namespace that allowed the Kim services to find our type services which until recently was an empty namespace.
          Hide
          Chad Hagstrom added a comment -

          After further discussion, it was decided that the Spring bean resource loaders should be reverted back to their former means of bean-searching (by the QName's toString() value instead of just its local part), and that the KEWServiceLocator and KIMServiceLocator should instead only add the module namespace to their QNames if the config parameters "kew.mode" and "kim.mode" (respectively) are set to "remote". The former change allows for services' bean names to match their bus-exposed names without running into wrong-service-returned problems, and the latter change allows for KEW and KIM remoting to continue to function correctly despite the resource loader modifications. In addition, I have undone the "ObjectRemoterService" changes mentioned in an earlier posting since they are no longer needed.

          Note, however, that there are at least six KEW and KIM services which (at least for this release) will never include the module namespace when accessed through the corresponding locator, regardless of the module's run mode: "enWorkflowUtilityService" (not to be confused with the non-"en" version), "enWorkflowDocumentActionsService" (not to be confused with the non-"en" version), and the four KIM service beans in the KIMInterfaceSpringBeans XML file and/or the KIMThinClientSpringBeans XML file ("kimIdentityManagementService", "kimRoleManagementService", "personService", and "kimAuthenticationService"). The two KEW services always exclude the namespace since they are currently exposed as beans and as blank-namespaced bus services, and the four KIM services always exclude the namespace because they are only accessible as beans and are not exposed on the bus. Rice might be changing the way it names its beans in a future release so that the Spring resource loaders would be able to find ones that include the namespaces in some format, but for now these changes and exclusions should be sufficient for this release.

          The above changes should fix the issues experienced recently concerning bean-naming and service-namespacing, but please post a comment on this issue if anyone is still experiencing more such problems after applying these new changes. I will be revising the related KRDOC issue shortly to reflect these changes.

          Aaron and Michal, I've attached another patch containing the KIM-related modifications, as well as an undo of the "ObjectRemoterService" and Spring bean resource loader changes in case you already applied them.

          Show
          Chad Hagstrom added a comment - After further discussion, it was decided that the Spring bean resource loaders should be reverted back to their former means of bean-searching (by the QName's toString() value instead of just its local part), and that the KEWServiceLocator and KIMServiceLocator should instead only add the module namespace to their QNames if the config parameters "kew.mode" and "kim.mode" (respectively) are set to "remote". The former change allows for services' bean names to match their bus-exposed names without running into wrong-service-returned problems, and the latter change allows for KEW and KIM remoting to continue to function correctly despite the resource loader modifications. In addition, I have undone the "ObjectRemoterService" changes mentioned in an earlier posting since they are no longer needed. Note, however, that there are at least six KEW and KIM services which (at least for this release) will never include the module namespace when accessed through the corresponding locator, regardless of the module's run mode: "enWorkflowUtilityService" (not to be confused with the non-"en" version), "enWorkflowDocumentActionsService" (not to be confused with the non-"en" version), and the four KIM service beans in the KIMInterfaceSpringBeans XML file and/or the KIMThinClientSpringBeans XML file ("kimIdentityManagementService", "kimRoleManagementService", "personService", and "kimAuthenticationService"). The two KEW services always exclude the namespace since they are currently exposed as beans and as blank-namespaced bus services, and the four KIM services always exclude the namespace because they are only accessible as beans and are not exposed on the bus. Rice might be changing the way it names its beans in a future release so that the Spring resource loaders would be able to find ones that include the namespaces in some format, but for now these changes and exclusions should be sufficient for this release. The above changes should fix the issues experienced recently concerning bean-naming and service-namespacing, but please post a comment on this issue if anyone is still experiencing more such problems after applying these new changes. I will be revising the related KRDOC issue shortly to reflect these changes. Aaron and Michal, I've attached another patch containing the KIM-related modifications, as well as an undo of the "ObjectRemoterService" and Spring bean resource loader changes in case you already applied them.
          Hide
          Chad Hagstrom added a comment -

          I'm resolving this now, but feel free to reopen it or to create a similar JIRA if anyone is still running into related service-naming or service-namespacing problems.

          Show
          Chad Hagstrom added a comment - I'm resolving this now, but feel free to reopen it or to create a similar JIRA if anyone is still running into related service-naming or service-namespacing problems.

            People

            • Assignee:
              Chad Hagstrom
              Reporter:
              David Elyea
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel