The main entry point for a bundle to the lifecycle API is the Activator. To use one, a bundle must declare it in its manifest, and provide the activator code. The manifest entry looks like this :
Bundle-Activator: org.phoenix.mybundle.MyActivator
Note that the activator may be imported from another bundle, or provided in the bundle classpath.
The bundle activator, as defined in the manifest of a bundle (Bundle-Activator), is the bundle's hook into the lifecycle layer. The bundle activator must implement the interface :
org.osgi.framework.BundleActivator
which defines two methods : start(BundleContext ctx) and stop(BundleContext ctx).
When a bundle is installed and started :
- OSGi framework creates an instance of the Activator;
- invokes the activator's start method.
- OSGi framework invokes the stop method (on the same instance of the activator, but may be in a different thread);
- releases the activator instance.
- On a restart, a new instance of the activator is created;
- the activator stop method should undo everything that was done in the start method.
The bundle context is provided to the bundle by the lifecycle layer. It allows the bundle to interact with the framework, access its context, modify it.... A bundle context is unique for a bundle, and is valid between the calls to the start and stop methods. A bundle's activator should not be shared with another bundle.
As exposed in the BundleContext interface listed above, the bundle context provides access to more than its owning bundle. It also allows to access other bundles, and through them to their context. Here is the Bundle interface :
The bundle ID is a runtime ID, generated by the framework. It's different from the bundle's static identifier, declared in its manifest.
The bundle location is usually an url, from which the bundle can be downloaded. But a bundle can also be loaded from an inputstream.
3. Bundle lifecycle
The schema below shows the famous bundle life cycle diagram.
No comments:
Post a Comment