Java Reference
In-Depth Information
More fundamentally, a destroy method may not be the best place to do your
cleanup. A destroy method will be called when a bundle is stopped, but after it's been
called you're only guaranteed that your bean won't be used by the Blueprint con-
tainer, not by poorly written clients. Even ignoring this, if a resource is only used by a
bean for a short period of time, a destroy method probably isn't the best way of clean-
ing it up. For example, holding a file handle open for the whole life of a bean may not
be ideal. On the other hand, if a resource is genuinely required for the lifespan of the
bean (that is, until the bundle is stopped), a destroy method is an appropriate and
safe way of cleaning up. However you tidy up, make sure that you correctly handle
calls when tidy-up is complete, even if that's by throwing an
IllegalStateException
.
There's a further catch—destroy methods can only be declared for singleton scope
beans. Even though destroy methods are a safe way of cleaning up resources, their
utility is limited. If you were busily plotting to use destroy methods for all of your
object cleanup, we're afraid you'll have to go back to the drawing board!
6.3.6
Service ranking
What happens when multiple services are registered, but a client requires only one?
Services may have a service ranking specified when they're registered:
<service
ref="specialOffer"
interface="fancyfoods.offers.SpecialOffer"
ranking="100"/>
When more than one service is available, the container will choose the highest-
numbered service available.
6.3.7
Registering services under multiple interfaces
In the examples so far, you've always used only one interface for each service you've
registered. But beans can be registered under multiple interfaces at the same time (as
long as they implement those interfaces):
<service
ref="specialOffer">
<interfaces>
<value>fancyfoods.offers.SpecialOffer</value>
<value>fancyfoods.some.other.UsefulInterface</value>
</interfaces>
</service>
Blueprint can also reflectively determine the interfaces under which a service should
be made available. In this case, it will be all the interfaces implemented by the bean:
<service
ref="specialOffer"
auto-export="interfaces"/>
