Java Reference
In-Depth Information
<bean
id="offer"
class="fancyfoods.fruit.BananaOffer">
<argument value="Bananas" />
<argument ref="anotherOffer" />
<argument value="5.42" />
<argument ref="time" />
</bean>
FACTORIES
Although the easiest way of instantiating a Blueprint bean is by direct construction,
this doesn't always line up well with how the bean class works. In that case, factories
can be defined instead. Factories can be used to drive any static method, even on code
you don't control.
The following snippet cunningly uses a bean factory to generate a timestamp.
Notice the use of the prototype scope to ensure that the timestamp is regenerated
each time, rather than once at application initialization:
<bean
id="time"
class="java.lang.System"
factory-method="currentTimeMillis"
scope="prototype"/>
Is construction all the initialization a bean will ever need? Sometimes yes, but some-
times beans need initialization in multiple phases.
6.3.5
Lifecycle callbacks
You've already seen in section 3.2.2 that it can sometimes be handy to do some bean ini-
tialization after all the properties have been set by specifying an
init-method.
(Con-
structors are also good at initializing objects. In some cases,
init-method
s can be
avoided by passing everything to a constructor using
<argument>
s instead of relying on
injected
<property>
elements.)
Blueprint also offers a
destroy-method
callback. The
destroy-method
is only sup-
ported for beans with singleton scope; beans with prototype scope must be destroyed
by the application.
The
destroy-method
can be used to clean up resources used by the bean. Because
singleton beans are only destroyed when a bundle is stopped,
destroy-method
s can
also be used more generally for bundle-level cleanup (see figure 6.4).
IS CLEANING UP IN DESTROY METHODS WISE?
How much can you rely on destroy methods for resource cleanup? Some Java pro-
grammers have an instinctive twitchiness whenever the subject of callbacks for
resource cleanup is mentioned. They remember the excitement they felt when they
first learned about Java finalizers, and the creeping disillusionment that followed
when they learned that
JVM
s don't guarantee calling finalizers, because they don't
guarantee garbage collecting unused objects. Many
JVM
s optimize garbage collection
