How to extend / amend OSGi lifecycle management?

Question

I have a modular application that uses OSGi for lifecycle and dependency management. However, some of the bundles require some time after startup to be ready, for example, because they have to acquire data from somewhere. Also, they might be unable to process certain calls during a configuration update, for example a bundle that keeps a connection to a db can't send queries while it is updating the connection parameters.

So, it seems to me that a bundle can have more subtle states than those managed by the OSGi container, and since they affect bundle interaction, there needs to be some handling. I can see three basic strategies for doing this:

• screw subtlety, and for example put all initialization code into BundleActivator.start(). If it takes forever to acquire that data, well then the bundle just won't be started forever. I'm not 100% sure that this would cover all cases, and it seems slightly wrong.
• fit my bundles with an additional event system that they use to notify each other of more subtle states like "momentarily unavailable" or "really ready now". This might simply be unnecessary overhead.
• have the bundle keep its more subtle state changes to itself and just take calls anyway, deferring them internally if necessary. This might not be appropriate when the caller could actually handle unavailability better.

Do you have any general advice on that? Is there even something in OSGi that I could use?

Answer 1

Try using services and service tracker to communicate between bundles. This will also help decouple your bundles as you'll likely be using interfaces.

Using you example of bundle which talks to a database:

1. Activator.start(), launch a background thread to do your initization business. Activators should execute quickly.
2. Register a service that provides the needed DB related abstraction for other bundles.
3. Other bundles create a service tracker to look for services they need,
4. Other bundles get a callback in the service tracker only when the first bundle registers the service. The first bundles only registers the service when it's ready implying that other bundles can begin using it immediately.