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

Identify work to decouple OJB and KNS from KRAD

    Details

    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 2.5
    • Component/s: JPA, KNS Equivalency
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Rice Module:
      KNS, KRAD
    • Application Requirement:
      Rice
    • Sprint:
      2.5.0-m2 Sprint 3, 2.5.0-m3 Sprint 1, Core 2.5.0-m3 Sprint 2, Core 2.5.0-m4 Sprint 1
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      There are some miscellaneous areas where KRAD still depends on pieces and parts of OJB and KNS so we can't cleanly remove them yet. Identify what needs to be done to remove these dependencies.

        Attachments

          Issue Links

            Activity

            Hide
            jkeller Jonathan Keller added a comment -

            Problems with extracting

            The structure and dependencies between the modules are causing serious problems with the removal of OJB in a way which won't break legacy applications.

            The primary source of the problems is the document framework. The main document class in Rice extends from the PBOB class which we need to move into the KNS package. (BusinessObject also needs to move - but it's used in a number of core API services and classes.)

            The division between the krad-app-framework and krad-web-framework modules is part of the problem. krad-app-framework can not see the KNS or krad-web-framework. LegacyDataAdapter is in krad-web-framework, but we need some of the functions in krad-app-framework. But, because it has references to the document framework, it can not be moved to the latter.

            I've been trying to remove references to PBO by creating a new base class for use in the shared objects which need to be bound to OJB as well as JPA. (called PersistableBusinessObjectBaseAdapter) This is a DataObjectBase extension with some additional methods to match what PBOB had. But...these methods require the LegacyDataAdapter.

            I've managed to address this by splitting the interface for the LDA into two, one inheriting from the other. (Still just the one implementation.)

            The larger problem is the business object service. It really expects some things to be business objects. Casting may be the answer, but I don't know if it will work in all cases. (Actually, I know it won't, since I can't reference the class to which I need to cast.) So, in these places (specific cases), I have been changing the API methods to take object instead of BusinessObject or PersistableBusinessObject. I know this would affect custom overrides, so this is an impacting change, but I don't think there are too many who are customizing the BO server.

            The more impacting change is the changing of some presentation controller classes. Those I expect (know) are being overridden. So, the change of the signature will force changes. (If people are using best practices and adding the @Override annotation, this will flag on compile.)

            The project is now compiling within Eclipse - but I'm having Maven issues - something with gmaven failing in Rice-impl on a test class. I still have not resolved that one.

            Show
            jkeller Jonathan Keller added a comment - Problems with extracting The structure and dependencies between the modules are causing serious problems with the removal of OJB in a way which won't break legacy applications. The primary source of the problems is the document framework. The main document class in Rice extends from the PBOB class which we need to move into the KNS package. (BusinessObject also needs to move - but it's used in a number of core API services and classes.) The division between the krad-app-framework and krad-web-framework modules is part of the problem. krad-app-framework can not see the KNS or krad-web-framework. LegacyDataAdapter is in krad-web-framework, but we need some of the functions in krad-app-framework. But, because it has references to the document framework, it can not be moved to the latter. I've been trying to remove references to PBO by creating a new base class for use in the shared objects which need to be bound to OJB as well as JPA. (called PersistableBusinessObjectBaseAdapter) This is a DataObjectBase extension with some additional methods to match what PBOB had. But...these methods require the LegacyDataAdapter. I've managed to address this by splitting the interface for the LDA into two, one inheriting from the other. (Still just the one implementation.) The larger problem is the business object service. It really expects some things to be business objects. Casting may be the answer, but I don't know if it will work in all cases. (Actually, I know it won't, since I can't reference the class to which I need to cast.) So, in these places (specific cases), I have been changing the API methods to take object instead of BusinessObject or PersistableBusinessObject. I know this would affect custom overrides, so this is an impacting change, but I don't think there are too many who are customizing the BO server. The more impacting change is the changing of some presentation controller classes. Those I expect (know) are being overridden. So, the change of the signature will force changes. (If people are using best practices and adding the @Override annotation, this will flag on compile.) The project is now compiling within Eclipse - but I'm having Maven issues - something with gmaven failing in Rice-impl on a test class. I still have not resolved that one.
            Hide
            kbtaylor Kristina Taylor (Inactive) added a comment -

            QA has reported some tests failing due to a stack overflow (KULRICE-12624) that look to be due to this changeset. Can you please investigate this?

            Show
            kbtaylor Kristina Taylor (Inactive) added a comment - QA has reported some tests failing due to a stack overflow ( KULRICE-12624 ) that look to be due to this changeset. Can you please investigate this?
            Hide
            jkeller Jonathan Keller added a comment -

            Done. After removing the (now ambiguous) signature and moving the behavior into the single method, the operations listed on the linked SR no longer produce a stack overflow.

            Show
            jkeller Jonathan Keller added a comment - Done. After removing the (now ambiguous) signature and moving the behavior into the single method, the operations listed on the linked SR no longer produce a stack overflow.
            Hide
            shahess Shannon Hess added a comment -

            Jonathan,

            SearchAttributeIndexRequestOjbTest and SearchAttributeIndexRequestTest were having some issues after DocumentHeader.java and DocumentBase.java changed to extend PersistableBusinessObjectBaseAdapter rather than PersistableBusinessObjectBase. For KULRICE-12651 and KULRICE-12650 I changed some methods to take Object instead of BusinessObject (based on what you said above.) If you think that any of my changes are ones that cannot be made due to other reasons just let me know and I can revert them.

            Classes where methods sig changed:

            • LookupUtils.java
            • BusinessObjectMetaDataServiceImpl.java
            • BusinessObjectMetaDataService.java

            Thanks,
            Shannon

            Show
            shahess Shannon Hess added a comment - Jonathan, SearchAttributeIndexRequestOjbTest and SearchAttributeIndexRequestTest were having some issues after DocumentHeader.java and DocumentBase.java changed to extend PersistableBusinessObjectBaseAdapter rather than PersistableBusinessObjectBase. For KULRICE-12651 and KULRICE-12650 I changed some methods to take Object instead of BusinessObject (based on what you said above.) If you think that any of my changes are ones that cannot be made due to other reasons just let me know and I can revert them. Classes where methods sig changed: LookupUtils.java BusinessObjectMetaDataServiceImpl.java BusinessObjectMetaDataService.java Thanks, Shannon
            Hide
            jkeller Jonathan Keller added a comment -

            Changing BO to Object should be fine as long as the method is not overloaded. (as we found)

            I would just check that they do not cast anything inside to PBO for use of some of their functions. (An issue I'm correcting in other places now.)

            Show
            jkeller Jonathan Keller added a comment - Changing BO to Object should be fine as long as the method is not overloaded. (as we found) I would just check that they do not cast anything inside to PBO for use of some of their functions. (An issue I'm correcting in other places now.)

              People

              • Assignee:
                jkeller Jonathan Keller
                Reporter:
                cniesen Claus Niesen
              • Votes:
                0 Vote for this issue
                Watchers:
                4 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