sampa : colin’s blog

The new alias tag in Spring’s XML bean definition format makes using Spring in a (lightweight) component oriented fashion significantly easier.

Spring has always had the ability to assign multiple IDs to components (via combined usage of the id and name attributes) which made it possible to link up components somewhat. Consider a library called ComponentA. It defines within it an XML application context fragment called componentA-context.xml. This is the bean definitions for the component. Now some of the component’s beans in there need to work with a DataSource, so they use a reference to a datasource bean:

  <ref bean="componentA-dataSource"/>

However, the component’s XML file fragment doesn’t actually define this datasource bean. It’s assumed that some application is going to be assembling an entire context by using multiple XML file fragments like this together, and the datasource will be defined elsewhere. So we might have another component, ComponentB, which in its definition file called componentB-context.xml, refers to the datasource under another name.

  <ref bean="componentB-dataSource"/>

Then finally we have the application’s main context definition file, called myApp-context.xml. Inside this are a bunch of bean definitions, including the actual definition for the datasource.

  <bean id="myApp-dataSource" name="componentA-dataSource,componentB-dataSource>
    . . . bean definition here
  </bean>

As you can see, the bean called myApp-dataSource is also given the aliases componentA-dataSource and componentB-dataSource so that the references by those names in the component XML file fragments will be able to match the right bean.

So this works great, but what happens if the main application doesn’t want to define the bean itself? Consider the case where componentA does actually define the dataSource. How can an application come along, pull in the definition for both components, and ensure that componentB’s bean definitions as well as any bean definitions in the main application context definition file can refer to the datasource somehow, without using the componentA-specific name?

With the new alias tag, this is trivial. The main application’s xml fragement would simply define:

  <alias name="componentA-dataSource" alias="componentB-dataSource"/>
  <alias name="componentA-dataSource" alias="myApp-dataSource"/>

Any bean definitions in componentB’s definition XML fragment can refer to componentB-dataSource, and any definitions in the main application XML fragment can refer to myApp-dataSource, and this will be resolved to the componentA-dataSource bean definition coming from ComponentA’s XML fragment.

Of course, you still have to worry yourself about name clashes. This is why I call this a lightweight component oriented approach. It’s quite possible for different XML file fragments which are assembled together for the final context, to accidentally use the same name for something. This is why it makes sense when using this approach to use some sort of prefix on bean names as a sort of namespacing scheme.