Spring framework is widely used as a dependency injection container, and that’s for good reasons. First of all, it facilitates integration testing and it gives us the power of customizing bean creation and initialization (e.g. @Autowired for List types).

But there is also a very useful feature, that might get overlooked and therefore let’s discuss about bean aliasing.

Bean aliasing allows us to override already configured beans and to substitute them with a different object definition. This is most useful when the bean definitions are inherited from an external resource, which is out of our control.

In the following example, I will show you how bean aliasing works. Let’s start with the following bean definition, coming from the src/main/resources/spring/applicationContext-tx.xml configuration file.

This context file contains many transaction/JPA related features we would like to use in our Integration Tests.

<bean id="dataSource" class="bitronix.tm.resource.jdbc.PoolingDataSource" init-method="init" destroy-method="close">
	<property name="className" value="${jdbc.driverClassName}"/>
	<property name="uniqueName" value="dataSource"/>
	<property name="minPoolSize" value="0"/>
	<property name="maxPoolSize" value="5"/>
	<property name="allowLocalTransactions" value="false" />
	<property name="driverProperties">
		<props>
			<prop key="user">${jdbc.username}</prop>
			<prop key="password">${jdbc.password}</prop>
			<prop key="url">${jdbc.url}</prop>
		</props>
	</property>
</bean>

<bean id="jtaTransactionManager" factory-method="getTransactionManager"
	class="bitronix.tm.TransactionManagerServices" depends-on="btmConfig, dataSource"
	destroy-method="shutdown"/>

The dataSource bean definition expects a XA Datasource, but since HSQLDB doesn’t provide one, I have to rely on LrcXADataSource to overcome this limitation. But this implies changing the DataSource to use a different className and driverProperties, and we cannot do that since the context definition comes from an external artifact.

Luckily, this is where bean aliasing comes to the rescue. This is how our Integration Testing context src/test/resources/spring/applicationContext-test.xml makes use of this handy feature:

<import resource="classpath:spring/applicationContext-tx.xml" />

<bean id="testDataSource" class="bitronix.tm.resource.jdbc.PoolingDataSource" init-method="init" destroy-method="close">
    <property name="className" value="bitronix.tm.resource.jdbc.lrc.LrcXADataSource"/>
    <property name="uniqueName" value="testDataSource"/>
    <property name="minPoolSize" value="0"/>
    <property name="maxPoolSize" value="5"/>
    <property name="allowLocalTransactions" value="false" />
    <property name="driverProperties">
        <props>
            <prop key="user">${jdbc.username}</prop>
            <prop key="password">${jdbc.password}</prop>
            <prop key="url">${jdbc.url}</prop>
            <prop key="driverClassName">${jdbc.driverClassName}</prop>
        </props>
    </property>
</bean>

<alias name="testDataSource" alias="dataSource"/>

I'm running an online workshop on the 20-21 and 23-24 of November about High-Performance Java Persistence.

If you enjoyed this article, I bet you are going to love my Book and Video Courses as well.

The testDataSource is of the same Class type with the inherited dataSource, but it comes with a different object configuration. This is the data source we would like to use every time a dataSource dependency is required, instead of the original variant. This is possible through the alias keyword, that’s instructing the dependency injection container to replace the original dataSource definition with the new version.

Insert details about how the information is going to be processed

DOWNLOAD NOW