method simply retrieves each of the Target beans declared in the ApplicationContext, triggering the
autowire process. Here is the output from running this example:
Using byName:
Property foo set
Using byType:
Property bar set
Property foo set
Property foo2 set
Using constructor:
Target(Foo, Bar) called
From the output, you can see that when Spring uses byName, the only property that is set is the foo
property, because this is the only property with a corresponding bean entry in the configuration file.
When using byType, Spring sets the value of all three properties. The foo and foo2 properties are set by
the foo bean, and the bar property is set by the bar1 bean. When using constructor, Spring uses the two-
argument constructor, because Spring can provide beans for both arguments and does not need to fall
back to another constructor.
When to Use Autowiring
In most cases, the answer to the question of whether you should use autowiring is definitely "no!"
Autowiring can save you time in small applications, but in many cases, it leads to bad practices and is
inflexible in large applications. Using byName seems like a good idea, but it may lead you to give your
classes artificial property names so that you can take advantage of the autowiring functionality. The
whole idea behind Spring is that you can create your classes how you like and have Spring work for you,
not the other way around. You may be tempted to use byType until you realize that you can have only
one bean for each type in your ApplicationContext--a restriction that is problematic when you need to
maintain beans with different configurations of the same type. The same argument applies to the use of
constructor autowiring.
In some cases, autowiring can save you time, but it does not really take that much extra effort to
define your wiring explicitly, and you benefit from explicit semantics and full flexibility on property
naming and on how many instances of the same type you manage. For any nontrivial application, steer
clear of autowiring at all costs.
Bean Inheritance
In some cases, you many need multiple definitions of beans that are the same type or implement a shared
interface. This can become problematic if you want these beans to share some configuration settings but
not others. The process of keeping the shared configuration settings in sync is quite error-prone, and on
large projects, doing so can be quite time-consuming. To get around this, Spring allows you to define a
<bean> definition that inherits its property settings from another bean in the same ApplicationContext.
You can override the values of any properties on the child bean as required, which allows you to have full
control, but the parent bean can provide each of your beans with a base configuration. Listing 4-76 shows
a simple configuration with two beans, one of which is the child of the other (app-context-xml.xml).
Search WWH :
