OSGi is fundamentally a dynamic technology. Bundles can be installed, started, stopped, updated, and uninstalled in a running system. To support this, bundles must have a clear lifecycle, and developers need ways of listening to and hooking into the various lifecycle states of a bundle (see Fig. 2-5).
Figure 2-5 Bundle lifecycle
Every bundle starts it runtime life in the installed state. From there it becomes resolved if all of its dependencies are met. Once a bundle is resolved, its classes can be loaded and run. If a bundle is subsequently started and transitions to the active state, it can participate in its lifecycle by having an activator. Using the activator, the bundle can initialize itself, acquire required resources, and hook in with the rest of the system. At some point—for example, on system shutdown—active bundles get stopped. Bundles with activators have a chance to free any resources they may have allocated. Bundles transition back to the resolved state when they are stopped. From there they may be restarted or uninstalled, at which time they are no longer available for use in the system.
All of this state changing surfaces as a continuous flow of events. Bundles support dynamic behavior by listening to these events and responding to the changes. For example, when a new bundle is installed, other bundles may be interested in its contributions.
The OSGi framework dispatches events when the state of the bundles, the services, or the framework itself changes.
- Service events—Fired when a service is registered, modified, or unregistered
- Bundle events—Fired when the state of the framework's bundles changes, for example, when a bundle is installed, resolved, starting, started, stopping, stopped, unresolved, updated, uninstalled, or lazily activated
- Framework events—Fired when the framework is started; an error, warning, or info event has occurred; the packages contributing to the framework have been refreshed; or the framework's start level has changed