Another good reason comes from Blueprint. Wiring beans from the same
bundle together needs to be done using bean references instead of services.
Otherwise, a circular dependency is created, where the Blueprint container
for the bundle won't initialize until it's found all the unsatisfied service refer-
ences. Because the unsatisfied service references are supposed to get regis-
tered by the waiting Blueprint container, this doesn't usually end well.
Blueprint allows you to declare a wide variety of Java objects using relatively simple XML .
These values can be passed to beans using <property> and <argument> elements.
Lists, sets, arrays, maps, and properties objects can also be specified in XML . To define
a map of foods and prices, you could use the following XML :
<entry key="Chocolate ice cream">3.99</entry>
The two forms of the <entry> element are equivalent. To define the same relationship
as a Properties object, the XML would be
<prop key="Chocolate ice cream">3.99</prop>
Null can be specified using <null> .
Beans can be instantiated with simple Java types or references to more complex Blue-
print-managed classes. The container will try to construct an appropriate object to
pass to the class's setter object from the XML parameters. It will automatically convert
XML strings into Java primitives, and it can initialize arbitrary Java classes if they have a
constructor that takes a simple String . Most impressively, Blueprint can use generic
type information to perform implicit type conversion for collection types. For exam-
ple, the following snippet calls a setShopClosedDates(List<Date> dates) method
that expects a List of Date objects:
<value>November 6, 1980</value>
<value>February 14, 1973</value>
When implicit conversion isn't good enough (or if you have nongeneric code), you
can explicitly specify types:
Search WWH ::