String
s2
=
(String)
ctx.getBean("name2");
String
s3
=
(String)
ctx.getBean("name3");
String
s4
=
(String)
ctx.getBean("name4");
String
s5
=
(String)
ctx.getBean("name5");
String
s6
=
(String)
ctx.getBean("name6");
System.out.println((s1
==
s2));
System.out.println((s2
==
s3));
System.out.println((s3
==
s4));
System.out.println((s4
==
s5));
System.out.println((s5
==
s6));
}
}
This code prints true five times to the console output for the configuration contained in Listing 4-68,
verifying that the beans accessed using different names are in fact the same bean.
You can retrieve a list of the bean aliases by calling ApplicationContext.getAliases(String) and
passing in any one of the bean's names or ID. The list of aliases, other than the one you specified, will
then be returned as a String array.
Bean name aliasing is a strange beast because it is not something you tend to use when you are
building a new application. If you are going to have many other beans inject another bean, then they
may as well use the same name to access that bean. However, as your application goes into production
and maintenance work gets carried out, modifications are made, and so on, bean name aliasing
becomes more useful.
Consider the following scenario: you have an application in which 50 different beans, configured
using Spring, all require an implementation of the Foo interface. Twenty-five of the beans use the
StandardFoo implementation with the bean name standardFoo, and the other 25 use the SuperFoo
implementation with the superFoo bean name. Six months after you put the application into production,
you decide to move the first 25 beans to the SuperFoo implementation. To do this, you have three options:
The first is to change the implementation class of the standardFoo bean to
·
SuperFoo. The drawback of this approach is that you have two instances of the
SuperFoo class lying around when you really need only one. In addition, you now
have two beans to make changes to when the configuration changes.
The second option is to update the injection configuration for the 25 beans that
·
are changing, which changes the beans' names from standardFoo to superFoo. This
approach is not the most elegant way to proceed--you could perform a find and
replace, but then rolling back your changes when management isn't happy means
retrieving an old version of your configuration from your version control system.
The third, and most ideal, approach is to remove (or comment out) the definition
·
for the standardFoo bean and make standardFoo an alias to the superFoo. This
change requires minimal effort, and restoring the system to its previous
configuration is just as simple.
Bean Instantiation Mode
By default, all beans in Spring are singletons. This means Spring maintains a single instance of the bean,
all dependent objects use the same instance, and all calls to ApplicationContext.getBean() return the
same instance. We demonstrated this in the previous example shown in Listing 4-64, where we were able
to use identity comparison (==) rather than the equals() comparison to check whether the beans were
the same.
Search WWH :
Custom Search
Previous Page
Spring Framework 3 Topic Index
Next Page
Spring Framework 3 Bookmarks
Home