Affects Version/s: 2.4
Fix Version/s: 2.6
Security Level: Public (Public: Anyone can view)
KULRICE-5657 Clean up configurers KULRICE-4066 Clean up configuration system KULRICE-7861 Cannot define datasource on KimConfigurer KULRICE-12310 Add dataSource property to CoreServiceConfigurer KULRICE-2579 Clean up xml bootstrap files KULRICE-5117 Clean up current issues with configurers in Rice KULRICE-13431 Implement a unit test that tests transactions across multiple datasources KULRICE-954 Hook up ability to override global rice datasource/jndi name with kew specific one in KEW configurer KULRICE-4662 Clean up KEW services KULRICE-228 Clean up lib directory
KAI Review Status:Not Required
KTI Review Status:Not Required
Code Review Status:Not Required
Include in Release Notes?:Yes
There is some cleanup that needs to be done on our datasource configuration, especially with regards to KRAD.
We have three different jndi locations referenced on our project related to KRAD, and (as far as I can tell) there should only be one:
Additionally, it currently requires bean overrides to deploy our KRAD sample app as client (non-bundled), and we need to clean that up as well. Dan Seibert had to go through some hoops to get this set up in our test environments, and he shared some info on what he had to do:
override the coreConfigurer bean (which is in RiceServiceRegistrySpringBeans.xml) to
- add a property: <property name="serverDataSource" ref="riceDataSource$
- modify the dataSource property to reference a client datasource bean (should perhaps be called clientDataSource)
override the kradApplicationDataSource alias from _KradSampleAppJpaSpringBeans.xml to reference clientDataSource instead
- For bundled config.xml, define both a client and server datasource pointing at the same DB.
- For client app config.xml, define both datasources pointing at separate DBs
- need to add rice.server.datasource.username & rice.server.datasource.password as well
We need to clean that up so that we can deploy the sample app in different vanilla configurations without resorting to bean overrides.
We will definitely need to document changes we make on our impacting changes wiki page so our customers have a heads up and can figure out how to clean their configurations up too.