Details
-
Type:
Improvement
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.1.0
-
Component/s: DSL for Services
-
Labels:None
-
Number of attachments :
Description
As far as possible, you should have exactly the same Spring configuration files in your integration tests as in the deployed environment. One likely point of difference concerns database connection pooling and transaction infrastructure. If you are deploying to a full-blown application server, you will probably use its connection pool (available through JNDI) and JTA implementation. Thus in production you will use a JndiObjectFactoryBean for the DataSource and JtaTransactionManager. JNDI and JTA will not be available in out-of-container integration tests, so you should use a combination like the Commons DBCP BasicDataSource and DataSourceTransactionManager or HibernateTransactionManager for them. You can factor out this variant behavior into a single XML file, having the choice between application server and 'local' configuration separated from all other configuration, which will not vary between the test and production environments. In addition, it is advisable to use properties files for connection settings: see the PetClinic application for an example.
TransactionManagers:
out-container: transaction.manager.class=org.springframework.orm.hibernate3.HibernateTransactionManager
in-container: transaction.manager.class=org.springframework.transaction.jta.JtaTransactionManager
Johan Vogelzang [02/dec/08 07:55 AM]
In the Spring config file RecordShopServiceLayerImplBaseContext.xml we can generate a alternative for
<tx:jta-transaction-manager> to be able to switch between JTA and non-JTA transactionmangers:
<!-- Transaction management alternative configuration for <tx:jta-transaction-manager> -->
<bean class="${transaction.manager.class}" id="transactionManager">
</bean>
The transaction.manager.class property must be defined in environment.poperties or mod4j.properties??
Johan Vogelzang [02/dec/08 07:59 AM]
When a suitable solution works, RecordShopServiceLayerTestContext.xml can be removed from RecordShop-service/src/test/resources (and tests)
Issue Links
| This issue is related to: | ||||
| MODFORJ-116 | Spring overriding-mechanism doesn't work when overriding the tra-transactionmanager with another transactionmanager in the /service/applicationContext.xml |
|
|
|
With the new Spring configuration setup (
MODFORJ-116), it is possible to splt of the transactionManager en dataSource and create alternative versions of them In a separate testContext. So they can be used for out-container tests and leave most of the Spring config as-is.MODFORJ-116), it is possible to splt of the transactionManager en dataSource and create alternative versions of them In a separate testContext. So they can be used for out-container tests and leave most of the Spring config as-is.