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.
Search WWH ::