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

Possible issues with remoting of KIM Type Services and attributes

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0.1, KFS Release 3.0
    • Component/s: Development
    • Labels:
      None
    • Similar issues:
      KULRICE-4666Evaluate "remote" KIM services
      KULRICE-4667Evaluate remote KIM services: analysis & decision
      KULRICE-7354Standalone server is attempting to load remotable attributes locally
      KULRICE-3516Possible issue with kim services getting exported twice
      KULRICE-4641Fix Remote Mode in KIM
      KULRICE-1342Create a new type of attribute to replace WorkflowAttribute, make a SOAP remoted version of this service
      KULRICE-5893Error messages need to be resolved on the remote services
      KULRICE-5561enabling features for working with custom remotable attributes
      KULRICE-4668Evaluate remote KIM services: implementation
      KULRICE-13703Create Document Type in sample app to test all types of remoteable attributes in document search
    • Rice Module:
      KIM
    • Application Requirement:
      KFS

      Description

      • I'm afraid the integration of the system with applicationUrl doesn't
        quite appear to be complete. I don't see anywhere where
        KimDataDictionaryAttributeDefintion.getApplicationUrl is actually called
        (besides the aforementioned commented out code)
      • Even with the KimDataDictionaryAttributeDefinition class in place,
        things like ControlDefinitions that use a values finder that only exists
        in the remote client application will not work, this is accessed when
        the following method is called:
        • AttributeDefinitionMap getAttributeDefinitions(String kimTypeId);
        • The problem here (I suspect) is that it will attempt to load the
          class for the values finder and if it's a class that exists within a
          client application classloading space (like KFS) we'll get a
          ClassNotFoundException
        • I haven't been able to confirm if this is the case or not, but based
          on what I'm seeing I think this is what will happen
        • It looks like an attempt to solve this was made previously with the
          commented out method on KimTypeService?
          • List<KeyLabelPair> getAttributeValidValues(String attributeName);
      • the performLookup method on KualiAction depends on the ability to load
        the bo class, this won't be possible if the business object class being
        loaded is remote!
        • Actually, we're close to not having this requirement, only place it's really
          being used (besides when querying responsibleModuleService) is when
          querying the businessobjectauthorizationservice to determine whether or
          not the value should be encrypted
      • i assume the above issue is also a problem with KualiAction.performInquiry

        Issue Links

          Activity

          Hide
          Ailish Byrne added a comment -

          see linked issue

          Show
          Ailish Byrne added a comment - see linked issue
          Hide
          Eric Westfall added a comment -

          Hi Jonathan, I'm trying to pull estimates together for the 1.0.1 work. Do you have a rough estimate on number of hours for this task? Thanks.

          Show
          Eric Westfall added a comment - Hi Jonathan, I'm trying to pull estimates together for the 1.0.1 work. Do you have a rough estimate on number of hours for this task? Thanks.
          Hide
          Jonathan Keller added a comment -

          Just thinking...

          Removal of application URL from all places: 2h

          Hmm...If a ClassNotFoundException is caught, then call the getValidValues method on the service. That will proxy to the call on the service that was commented out. That one can be assumed to be running in the context of the source application with access to its classes and can then use the appropriate key values finder to return a list of KeyLabelPair objects. (I'll probably change the method to take an attribute definition.)

          So, that will probably take a few hours. I think I'll round the whole job to 16 to handle the other strange issues I'm sure will come up with regard to lookups and inquiries.

          Show
          Jonathan Keller added a comment - Just thinking... Removal of application URL from all places: 2h Hmm...If a ClassNotFoundException is caught, then call the getValidValues method on the service. That will proxy to the call on the service that was commented out. That one can be assumed to be running in the context of the source application with access to its classes and can then use the appropriate key values finder to return a list of KeyLabelPair objects. (I'll probably change the method to take an attribute definition.) So, that will probably take a few hours. I think I'll round the whole job to 16 to handle the other strange issues I'm sure will come up with regard to lookups and inquiries.
          Hide
          Jonathan Keller added a comment -

          Ohhhhhh.....this is ugly!

          I've made the changes to the services to make the attribute definition lookups possible, but the problem goes much deeper. The values finder call happens in FieldUtils - where it instantiates the values finder using reflection, so I can't pass any information into it. So, I looked into making the information available there. That's when I realized that the entire Field system uses the component CLASS everywhere. In this case it would be KfsKimAttributes - which won't resolve.

          Also the existing code which handles the lookup parameters and field conversions in KimTypeServiceBase tries to resolve the class as well, so this may never have worked when remoted.

          I'm checking into where the various code is when executed, we may be saved by some of those aspects. I just checked and it looks like, on the KIM documents, that the value list is being called from the web layer through ActionFormUtilMap, so there may be hope.

          BTW, Eric - how is document search handling this? Is it able to get the value finder information from the client system already?

          Show
          Jonathan Keller added a comment - Ohhhhhh.....this is ugly! I've made the changes to the services to make the attribute definition lookups possible, but the problem goes much deeper. The values finder call happens in FieldUtils - where it instantiates the values finder using reflection, so I can't pass any information into it. So, I looked into making the information available there. That's when I realized that the entire Field system uses the component CLASS everywhere. In this case it would be KfsKimAttributes - which won't resolve. Also the existing code which handles the lookup parameters and field conversions in KimTypeServiceBase tries to resolve the class as well, so this may never have worked when remoted. I'm checking into where the various code is when executed, we may be saved by some of those aspects. I just checked and it looks like, on the KIM documents, that the value list is being called from the web layer through ActionFormUtilMap, so there may be hope. BTW, Eric - how is document search handling this? Is it able to get the value finder information from the client system already?
          Hide
          Jonathan Keller added a comment -

          OK, I think all this is working now. I don't know if there is anything to do with document search, but those lookups seem to be working properly,

          Show
          Jonathan Keller added a comment - OK, I think all this is working now. I don't know if there is anything to do with document search, but those lookups seem to be working properly,

            People

            • Assignee:
              Jonathan Keller
              Reporter:
              Eric Westfall
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 2 days
                2d
                Remaining:
                Remaining Estimate - 2 days
                2d
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Structure Helper Panel