TM on tests w/ "non-autowire by type" contexts ?

[Mordred]

I don't understand how automatic transaction management on tests using context files that cannot work with autowire by type is supported using AbstractTransactionalDataSourceSpringContextTests. The Spring ref states in topic "22.2.2 Dependency Injection of test class instances" :

The superclasses use autowire by type. Thus if you have multiple bean definitions of the same type, you cannot rely on this approach for those particular beans. In that case, you can use the inherited applicationContext instance variable, and explicit lookup using getBean().

Explicit lookup on an instance which is autowired by type to bypass autowire by type ?

in my case, I have a dataAccessContext file with multiple dataSource bean definitions, reusing that in getConfigLocations() results in a org.springframework.beans.factory.UnsatisfiedDepen dencyException being thrown. Since the dataSource is not properly injected I have no applicationContext instance.

So what's my best solution here ?

[Mordred]

Just as a note, I dislike creating separate context files for tests, duplicate configurations and the likes ...

[haninaguib]

Just as a note, I dislike creating separate context files for tests, duplicate configurations and the likes ...

You only need to define the beans which are specific to your test in a
separate file and inherit all others from your original context file. This seems
to me a much cleaner way, than ending up with a huge file containing all
the different variations of all your beans.

[Mordred]

I absolutely agree with you haninaguib, though I'm not sure why you would think I would want it any other way.

Maybe an example clarifies what I exactly mean :

applicationContext.xml

<bean id="myBusinessObject" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
		<property name="transactionManager"><ref bean="myTransactionManager"/></property>
		...
</bean>

dataAccessContext-local.xml

<bean id="myDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
	...
</bean>

<bean id="anotherDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
	... // pointing to another DB server
</bean>

<bean id="myTransactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
		<property name="dataSource"><ref local="myDataSource"/></property>
</bean>

test-beans.xml

<bean id="myTestBean" class="package.SpringTransactionTest">
        <property name="businessObject"><ref bean="myBusinessObject"/></property>
</bean>

test class

protected String[] getConfigLocations() {
        return new String[] {"applicationContext.xml", "dataAccessContext-local.xml", "test-beans.xml"};
}

So the test expects "myBusinessObject" injected, but runs into the exception mentioned earlier, stating I have to many beans of type javax.sql.DataSource. Which seems logical, because it's autowire by type.

So I can't use that approach, as the doc states. What I don't understand is that in such a case the doc states I should use the inherited (= depending on dependency injected dataSource) applicationContext instance, because the DI fails, hence I lose my capabilities of transaction managed testing ?

A possible solution, the approach of using a dedicated test context file for the test class means not reusing the dataAccessContext file if I want to make this work, but I simply wonder if there are better alternatives.

Thank you for answering in any case.