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 Task
    • Status: Closed Closed
    • Priority: Critical 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
    • Similar issues:
      KULRICE-11498Configure JPA entity manager factory and krad-data integration for KEN
      KULRICE-11499Configure JPA entity manager factory and krad-data integration for KCB
      KULRICE-3856JPA - Modify creation of PersistenceUnit such that it automatically imports persistent classes from the KNS that may need to be joined with client-side
      KULRICE-9739Improve ease of configuration of JPA for a module that is using KRAD
      KULRICE-5447KRAD application header/controls - persistence on page
      KULRICE-6014JPA Conversion Guide
      KULRICE-9553Implement concept of a "Conversation" managed by the framework, to support extended persistence contexts for lazy loading
      KULRICE-9538Convert KRAD data objects to krad-data and JPA
      KULRICE-9071Implement JPA version of PersistenceProvider
      KULRICE-9108Implement support for loading of both OJB and JPA versions of KRAD client-side mappings
    • 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.

        Activity

        Hide
        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
        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
        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
        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
        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
        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 -->
        Hide
        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
        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
        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
        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.
        Hide
        Eric Westfall added a comment -

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

        Show
        Eric Westfall added a comment - Changed description of this reflect focus on the JPA managed class/packages import.

          People

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

                Agile

                  Structure Helper Panel