Java Reference
In-Depth Information
The previous example demonstrates a pattern that's occasionally useful. Because the
bean exposed as a service is prototype scoped, a new one will be created for each bun-
dle that requests the service (though successive requests return the same object; see
ServiceFactory
in appendix A for details).
The following Blueprint snippet declares the same bean inline, which therefore
has an implicit prototype scope. The runtime behavior is identical to the previous
example:
<service interface="fancyfoods.offers.SpecialOffer">
<bean
class="fancyfoods.department.cheese.offers.DesperateCheeseOffer"/>
</service>
The scope of a bean affects more than how many
Object
instances you end up with. It
also has implications for how the bean is constructed and how its lifecycle is managed.
6.3.4
Constructing beans
Beans can be instantiated lazily or eagerly. Eager instantiation is the default for singleton
beans; however, this default can be changed for all the singleton beans in a Blueprint
XML
file. Beans with prototype scope are always constructed lazily because that's the only
way that makes sense. You may find for some singletons lazy activation is more efficient:
<bean
id="microwaveMeal"
class="fancyfoods.food.MicrowaveMeal"
activation="lazy"/>
Lazy activation is often a good thing in enterprise applications, because otherwise
they can take rather a long time to start. As a result, the Blueprint container offers
much more laziness than bean instantiation. For reasons we'll discuss further in the
section on damping, Blueprint
<reference>
objects are proxies to the real service.
This means that the Blueprint container doesn't have to look up the service until it's
first used. Another place in which Blueprint is particularly lazy is when it comes to
registering services on your behalf. Rather than eagerly creating the service object,
the Blueprint container registers a
ServiceFactory
object. A
ServiceFactory
allows
you to create your service object when it's first looked up, rather than when it's first
registered. If you want more control, then you can write your own
ServiceFactory
and then treat it like a normal Blueprint service. The Blueprint container is smart
enough to delegate to your
ServiceFactory
when a service is needed. If you're inter-
ested in writing a
ServiceFactory
, we suggest having a look at
OSG
i in Action
(Hall et
al., Manning Publications, 2011).
CONSTRUCTOR ARGUMENTS
So far, you've always used Blueprint beans with a no-argument constructor. But this is
by no means required. Any number of
<argument>
elements may be used to pass argu-
ments to a constructor. The order in the Blueprint file determines their order in the
constructor. Arguments may even refer to other beans or services:
