Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Major 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
    • Similar issues:
      KULRICE-12044Decouple OJB and KNS from KRAD
      KULRICE-4985decouple non-people from people
      KULRICE-9133Convert External Identifier Type to KRAD
      KULRICE-12293KNS/OJB Legacy Documents
      KULRICE-10127Create section in document for conversion from KNS+OJB to KRAD+JPA
      KULRICE-9113Eliminate compile time and runtime dependencies for OJB from krad code
      KULRICE-9862Identify permission gaps between KNS and KRAD inquiry features
      KULRICE-9863Identify inquirable gaps between KNS and KRAD inquiry features
      KULRICE-3993Need stepwise plan for decoupling from hosted environment
      KULRICE-8800Identify gaps between KNS and KRAD lookup features
    • 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.

        Issue Links

          Activity

          Hide
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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:
              Jonathan Keller
              Reporter:
              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

                  Agile

                    Structure Helper Panel