[KULRICE-9872] Implement a simple approach for importing common KRAD JPA entities into a KRAD application's persistence context Created: 05/Jul/13  Updated: 21/Apr/14  Resolved: 14/Aug/13

Status: Closed
Project: Kuali Rice Development
Component/s: Development, JPA
Affects Version/s: None
Fix Version/s: 2.4
Security Level: Public (Public: Anyone can view)

Type: Task Priority: Critical
Reporter: Jonathan Keller Assignee: Jonathan Keller
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Epic Link: JPA Support
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.



 Comments   
Comment by Eric Westfall [ 06/Jul/13 ]

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.

Comment by Jonathan Keller [ 08/Jul/13 ]

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.

Comment by Jonathan Keller [ 08/Jul/13 ]

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 -->
Comment by Jonathan Keller [ 30/Jul/13 ]

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.

Comment by Jonathan Keller [ 30/Jul/13 ]

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.

Comment by Eric Westfall [ 09/Aug/13 ]

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

Generated at Mon Oct 26 05:13:47 CDT 2020 using JIRA 7.0.11#70121-sha1:19d24976997c1d95f06f3e327e087be0b71f28d4.