Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-3455

Possible issues with remoting of KIM Type Services and attributes

    Details

    • Type: Bug Fix
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0.1, KFS Release 3.0
    • Component/s: Development
    • Labels:
      None
    • 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

        Attachments

          Issue Links

            Activity

            Hide
            abyrne Ailish Byrne added a comment -

            see linked issue

            Show
            abyrne Ailish Byrne added a comment - see linked issue
            Hide
            ewestfal 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
            ewestfal 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
            jkeller 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
            jkeller 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
            jkeller 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
            jkeller 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
            jkeller 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
            jkeller 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:
                jkeller Jonathan Keller
                Reporter:
                ewestfal 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