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

Rice DataDictionary files can "conflict" with Client app files.

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Won't Fix
    • Affects Version/s: KC Release 2.0, 1.0.2
    • Fix Version/s: KC Release 2.0, 1.0.2
    • Component/s: Development
    • Labels:
      None
    • Similar issues:
      KULRICE-4972DataDictionary uses a single spring context for all DD files which can result in unknown bean id conflicts
      KULRICE-9695DataDictionary loading DD files from package is broken
      KULRICE-6399Make configuring the reloading data dictionary easier for client app developers
      KULRICE-11994Load-Time Weaving should be optional for Rice client apps
      KULRICE-6281Integrate converted online help files into Rice
      KULRICE-1728KENBootstrap.xml file needs user 'admin' added to allow valid ingestion according to confluence page on Rice setup of sample app
      KULRICE-5096Generated Rice Client Application Project Skeleton always shows sample app links
      KULRICE-3475for client app db imports, rice dbs project needs to be checked out under the client app dir to avoid scheduling conflicts
      KULRICE-6749Configure rice sample app as a client app running against a standalone server
      KULRICE-6122Create "Getting Started" guide for client app developers
    • Rice Module:
      KNS
    • Application Requirement:
      KC

      Description

      Currently KC & rice both have datadictionary files containing the same spring bean names but referring to separate BusinessObjects. For example both KC and Rice have State DD files. This creates issues when trying to use the rice maintenance screens because KC's dd files are essentially overriding the rice dd files.

      We need a way for both DD definitions to live in harmony.

      See the linked issues for a list of conflicts.

        Activity

        Hide
        Eric Westfall added a comment -

        The campus, state, country, etc. tables exist in the Rice standalone server's database. So it wouldn't be possible to link to them from your KC ojb files. I think KFS handles these with ExternalizableBusinessObjects. That may require more refactoring then is sane given the timeline of the KC release though.

        Show
        Eric Westfall added a comment - The campus, state, country, etc. tables exist in the Rice standalone server's database. So it wouldn't be possible to link to them from your KC ojb files. I think KFS handles these with ExternalizableBusinessObjects. That may require more refactoring then is sane given the timeline of the KC release though.
        Hide
        Jeremy Hanson added a comment -

        So the best solution is probably just to rename them for now so they don't conflict, and KC ideally would switch to use Rice's BOs in a later release?

        Show
        Jeremy Hanson added a comment - So the best solution is probably just to rename them for now so they don't conflict, and KC ideally would switch to use Rice's BOs in a later release?
        Hide
        Travis Schneeberger added a comment -

        That sounds like a good option. I'll go ahead and make a KC jira to investigate this solution post 2.0 release.

        Show
        Travis Schneeberger added a comment - That sounds like a good option. I'll go ahead and make a KC jira to investigate this solution post 2.0 release.
        Hide
        Eric Westfall added a comment -

        I wonder if this will impact KFS. Jeremy, can you add this one to the KTI agenda to discuss.

        Show
        Eric Westfall added a comment - I wonder if this will impact KFS. Jeremy, can you add this one to the KTI agenda to discuss.
        Hide
        Jeremy Hanson added a comment -

        It was decided at the KTI that changing these in Rice would be to impacting on the the other projects, so the renaming will have to be done in KC.

        We still need to find a broader way to fix this for future releases, whether this is through code or just naming conventions.

        Show
        Jeremy Hanson added a comment - It was decided at the KTI that changing these in Rice would be to impacting on the the other projects, so the renaming will have to be done in KC. We still need to find a broader way to fix this for future releases, whether this is through code or just naming conventions.

          People

          • Assignee:
            Jeremy Hanson
            Reporter:
            Travis Schneeberger
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel