how to detect if a bundle is completely loaded in osgi container?

Question

is there any kind of event listeners like the ones in BundleEvent Class for detecting if a bundle is completely loaded and available for requests?

I made a search and all i could find is this

which doesnt use event listeners and means that i need to check manually or periodically (i didnt test that piece of code by the way.

are there any events like BundleEvent.STARTING for a load operation? or we need to implement one by ourselves (if possible) ?

Answer 1

There is no way for the OSGi framework to know when your bundle is "ready" for business. The framework can of course make sure your bundle's code dependencies are resolved for allowing classes to be loaded. But any other dependencies are unknowable by the framework. Only your bundle can know when it is ready for business. You can have it advertise this perhaps by having register a service which denotes this.

Answer 2

As BJ mentioned, one option is to use OSGi services. For example, bundle B will wait for a service to appear. When bundle A is ready (eg., activation finished) it registers a service. This will notify bundle B. You can use a ServiceTracker for that.

Another option is to use a BundleTracker . In the activator of bundle B you can register a BundleTracker that gets notified for STARTED state of bundles. However, you also want to monitor other states so that you'll discover when bundles go away.

Answer 3

In OSGi, there are two kinds of dependencies. The first kind is basically to setup an environment in which your bundle can run in a safe way. This includes code dependencies and other dependencies that you can express in your manifest. The framework ensures that these dependencies are met before it resolves you bundles. If those dependencies are not met, you won't be able to run a single instruction.

The second kind of dependencies are more dynamic, your code should be able to handle them in runtime when they change. In OSGi, these dependencies are best expressed services. With Declarative Services (specifically with the annotations) it is trivial to depend on others (Please, please don't use Service Tracker for this, DS is far, far, far superior).

So as the other responders said, ready is in the eye of the beholder. In OSGi, when you express your dependencies on services the problem shifts away from the bundle is ready, to: is there a service X? As long as the registrar of service X follows these rules as well you have a very robust and resilient application model. Since the framework and DS strictly follow the life cycle rules many different kinds of reasons why a bundle is ready or not collapse in a single model: the service.

Short example, Service Y depends on service X:

@Component 
public class YImpl implements Y {

   @Activate
   void activate() { /* only called when X is registered */ }
   @Reference
   void setX( X x ) {
      this.x = x;
   }

}