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

Implement a simple approach for importing common KRAD JPA entities into a KRAD application's persistence context

    Details

    • Type: Task
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.4
    • Component/s: Development, JPA
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Epic Link:
    • Rice Module:
      KRAD
    • Sprint:
      JPA Sprint 4, 2.4.0-m2 Sprint 1
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      Make the configuration of the data layer require as little duplication of core configuration as possible. There should be no need to duplicate large sets of beans. Reusable definitions should be able to be sourced (<import>) rather than duplicated.

        Attachments

          Activity

          jkeller Jonathan Keller created issue -
          jkeller Jonathan Keller made changes -
          Field Original Value New Value
          Epic Link KULRICE-9503 [ 115341 ]
          Hide
          ewestfal Eric Westfall added a comment -

          Jonathan, what are your specific thoughts on this one? Incidentally, I'm not a big fan of using imports as a way to configure the application because it seems like it introduces dependencies into the mix, like needing to know the ids of the beans generated, or what beans need to exist already that the imported resource depends on, etc. There's no great way to specific these dependencies with an import that way.

          One thing we should consider in order to streamline things would be the custom approach that spring takes, like <context:load-time-weaver/>. That seems a bit cleaner because it defaults as much as it can, but it also allows for additional injection to take place when needed and it can be explicitly documented in the custom schema.

          Show
          ewestfal Eric Westfall added a comment - Jonathan, what are your specific thoughts on this one? Incidentally, I'm not a big fan of using imports as a way to configure the application because it seems like it introduces dependencies into the mix, like needing to know the ids of the beans generated, or what beans need to exist already that the imported resource depends on, etc. There's no great way to specific these dependencies with an import that way. One thing we should consider in order to streamline things would be the custom approach that spring takes, like <context:load-time-weaver/>. That seems a bit cleaner because it defaults as much as it can, but it also allows for additional injection to take place when needed and it can be explicitly documented in the custom schema.
          Hide
          jkeller Jonathan Keller added a comment -

          This was something I experimented with as part of getting the Converter registration to be automatic. One problem we had in the configuration of the sample app and the KIM module was that the "packages to scan" needed to list all the KRAD packages or things would not work.

          So, what I did was to create multiple lists of packages:

          • coreJpaPackagesToScan
          • kradJpaPackagesToScan
          • moduleJpaPackagesToScan

          And then those are merged by a default bean into the single list: jpaPackagesToScan, which is used by the entity manager.

          The problem I have at the moment is that merging bean is being defined in each of the modules because of the lack of an included file in which I can put the definition.

          I also have a problem with most of the beans in the KIM and sample app module bean definitions, as they need to duplicate most of the data-access beans. (entity manager, transaction manager, etc...)

          Since everything is in their own context, we should be able to provide an include file which creates all these beans, using properties (like the "module" packages to scan) which customize their behavior as needed.

          Show
          jkeller Jonathan Keller added a comment - This was something I experimented with as part of getting the Converter registration to be automatic. One problem we had in the configuration of the sample app and the KIM module was that the "packages to scan" needed to list all the KRAD packages or things would not work. So, what I did was to create multiple lists of packages: coreJpaPackagesToScan kradJpaPackagesToScan moduleJpaPackagesToScan And then those are merged by a default bean into the single list: jpaPackagesToScan, which is used by the entity manager. The problem I have at the moment is that merging bean is being defined in each of the modules because of the lack of an included file in which I can put the definition. I also have a problem with most of the beans in the KIM and sample app module bean definitions, as they need to duplicate most of the data-access beans. (entity manager, transaction manager, etc...) Since everything is in their own context, we should be able to provide an include file which creates all these beans, using properties (like the "module" packages to scan) which customize their behavior as needed.
          Hide
          jkeller Jonathan Keller added a comment - - edited

          Example from sampleapp: /rice-krad-sampleapp/src/main/resources/_KradSampleAppJpaSpringBeans.xml

            <!-- JHK: Should be defined centrally -->
            <bean id="jpaPackagesToScan" 
            		class="org.kuali.rice.core.framework.util.spring.ListMergeBeanFactory">
            		<constructor-arg>
            			<list>
            				<ref bean="coreJpaPackagesToScan"/>
            				<ref bean="kradJpaPackagesToScan"/>
            				<ref bean="moduleJpaPackagesToScan"/>
            			</list>
            		</constructor-arg>
            </bean>
          
            <util:list id="moduleJpaPackagesToScan">
              <!-- Sample app specific -->
              <value>org.kuali.rice.krad.demo.travel.dataobject</value>
              <value>org.kuali.rice.krad.demo.travel.authorization</value>
            </util:list>
          
            <bean id="entityManagerFactory"
                  class="org.kuali.rice.krad.data.provider.jpa.eclipselink.KradEclipseLinkEntityManagerFactoryBean"
                  p:jtaDataSource-ref="riceDataSource"
                  p:persistenceUnitName="krad-sample-app"
                  p:packagesToScan-ref="jpaPackagesToScan"/>  <!-- merged list -->
          
          Show
          jkeller Jonathan Keller added a comment - - edited Example from sampleapp: /rice-krad-sampleapp/src/main/resources/_KradSampleAppJpaSpringBeans.xml <!-- JHK: Should be defined centrally --> <bean id= "jpaPackagesToScan" class= "org.kuali.rice.core.framework.util.spring.ListMergeBeanFactory" > <constructor-arg> <list> <ref bean= "coreJpaPackagesToScan" /> <ref bean= "kradJpaPackagesToScan" /> <ref bean= "moduleJpaPackagesToScan" /> </list> </constructor-arg> </bean> <util:list id= "moduleJpaPackagesToScan" > <!-- Sample app specific --> <value>org.kuali.rice.krad.demo.travel.dataobject</value> <value>org.kuali.rice.krad.demo.travel.authorization</value> </util:list> <bean id= "entityManagerFactory" class= "org.kuali.rice.krad.data.provider.jpa.eclipselink.KradEclipseLinkEntityManagerFactoryBean" p:jtaDataSource-ref= "riceDataSource" p:persistenceUnitName= "krad-sample-app" p:packagesToScan-ref= "jpaPackagesToScan" /> <!-- merged list -->
          masargen Matt Sargent made changes -
          Documentation Review Status Pending Review [ 14643 ] Not Required [ 14642 ]
          ewestfal Eric Westfall made changes -
          Rank Ranked higher
          ewestfal Eric Westfall made changes -
          Original Estimate 4 days [ 115200 ]
          ewestfal Eric Westfall made changes -
          Remaining Estimate 4 days [ 115200 ]
          ewestfal Eric Westfall made changes -
          Sprint JPA Sprint 4 [ 35 ]
          jkeller Jonathan Keller made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Hide
          jkeller Jonathan Keller added a comment -

          TODO: Eliminate the need to duplicate all those core JPA beans in each module. Have them part of the base setup or provide a common <include> file which can be used.

          Show
          jkeller Jonathan Keller added a comment - TODO: Eliminate the need to duplicate all those core JPA beans in each module. Have them part of the base setup or provide a common <include> file which can be used.
          Hide
          jkeller Jonathan Keller added a comment -

          Custom schema?

          <krad-data:jpa />

          look for DS and spring context
          default persistence unit name

          Should also make list of provider beans which can be appended to.

          Show
          jkeller Jonathan Keller added a comment - Custom schema? <krad-data:jpa /> look for DS and spring context default persistence unit name Should also make list of provider beans which can be appended to.
          ewestfal Eric Westfall made changes -
          Rank Ranked higher
          ewestfal Eric Westfall made changes -
          Sprint JPA Sprint 4 [ 35 ] JPA Sprint 4, JPA Sprint 5 [ 35, 45 ]
          ewestfal Eric Westfall made changes -
          Sprint JPA Sprint 4, JPA Sprint 5 [ 35, 45 ] JPA Sprint 4 [ 35 ]
          ewestfal Eric Westfall made changes -
          Rank Ranked higher
          Hide
          ewestfal Eric Westfall added a comment -

          Changed description of this reflect focus on the JPA managed class/packages import.

          Show
          ewestfal Eric Westfall added a comment - Changed description of this reflect focus on the JPA managed class/packages import.
          ewestfal Eric Westfall made changes -
          Summary Streamline JPA configuration and eliminate duplication by implementing modules Implement a simple approach for importing common KRAD JPA entities into a KRAD application's persistence context
          Original Estimate 4 days [ 115200 ] 1 day [ 28800 ]
          Remaining Estimate 4 days [ 115200 ] 1 day [ 28800 ]
          jcoltrin Jessica Coltrin (Inactive) made changes -
          Sprint JPA Sprint 4 [ 35 ] JPA Sprint 4, 2.4.0-m2 Sprint 1 [ 35, 54 ]
          jcoltrin Jessica Coltrin (Inactive) made changes -
          Fix Version/s 2.4.0-m1 [ 17035 ]
          jkeller Jonathan Keller made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          spatterson Shem Patterson (Inactive) made changes -
          Workflow custom [ 203687 ] Copy of custom for rice [ 208465 ]
          spatterson Shem Patterson (Inactive) made changes -
          Workflow Copy of custom for rice [ 208465 ] custom [ 218213 ]
          spatterson Shem Patterson (Inactive) made changes -
          Workflow custom [ 218213 ] Rice Workflow [ 227961 ]
          jcoltrin Jessica Coltrin (Inactive) made changes -
          Fix Version/s 2.4.0-m2 [ 17036 ]
          jcoltrin Jessica Coltrin (Inactive) made changes -
          Fix Version/s 2.4.0-m2 [ 17036 ]
          jcoltrin Jessica Coltrin (Inactive) made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              jkeller Jonathan Keller
              Reporter:
              jkeller Jonathan Keller
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1 day
                1d
                Remaining:
                Remaining Estimate - 1 day
                1d
                Logged:
                Time Spent - Not Specified
                Not Specified