Java Reference
In-Depth Information
destroy-method
Blueprint
container
Stopping
stop
Resolved
init-method
start
Active
Starting
Figure 6.4
The lifecycle of a bundle's Blueprint container and Blueprint beans is closely tied to the bun-
dle's lifecycle. The
init-method
is called on eager singleton beans after the container is started; the
destroy-method
is called when the bundle is stopped.
times by doing everything they can to avoid collecting objects with potentially expen-
sive
finalize()
methods.
Will you fall into the same trap if you rely on destroy methods? Yes and no. Your
destroy methods will certainly be called by the Blueprint container, unlike a finalizer,
but you should still exercise some caution in using them.
In particular, you should try to avoid calling other services (including injected ser-
vices) in destroy methods. If your Blueprint bean is in the process of going away,
there's a chance that the system is shutting down or in some unstable state, and other
services have already disappeared. If you try to use those services, you risk a long Blue-
print timeout, and a
ServiceUnavailableException
at the end. In principle this
should never happen, because the Blueprint specification requires that beans be
destroyed in reverse dependency order. But this doesn't help you when using services
that aren't managed by Blueprint. A bug in versions of Aries Blueprint below 0.4 also
meant that calls to Blueprint-injected services in destroy methods were unreliable.
