 |  |  |  |  |
| | | | |
 |  |
The OSGi Lifecycle layer manages lifecycle for each bundle and allows updates of existing bundles. The Lifecycle layer provides runtime module management to install and manage bundles in the OSGi framework. This lifecycle management allows you to manage your application dynamically and remotely. You can install, start, stop, and restart bundles and update an installed bundle without restarting the JVM.
The Lifecycle layer API controls the security and lifecycle operations of bundles, providing a runtime model for bundles. The Lifecycle layer provides a comprehensive event API to allow a management bundle to control the operations of the service platform.
The Lifecycle layer provides application management:
Internal to the application — Defines how bundles access the execution context and interact with the OSGi framework and facilities during execution
External to the application — Defines bundle operations, including install, update, start, stop, and uninstall
The lifecycle layer defines how bundles are dynamically installed and managed in the OSGi framework:
Definition of the lifecycle operations — Install, update, start, stop, uninstall
Defines how bundles gain access to their execution context — The execution context provides a way to interact with the OSGi framework and its facilities during execution
Dependencies between the bundle owning a service and the bundles using the service are managed by the Framework. For example, when a bundle is stopped, all the services registered with the Framework by that bundle must be automatically unregistered.
Applications in an OSGi environment are subject to the lifecycle of its bundles. Bundles have six lifecycle states:
Installed — All bundles start in the installed state. Bundles in the installed state are waiting for all of their dependencies to be resolved. Once all of a bundle's dependencies are resolved, it moves to the next lifecycle state.
Resolved — Bundles are moved to the resolved state when the following conditions are met:
The runtime environment meets or exceeds the environment specified by the bundle.
All of the packages imported by the bundle are exposed by bundles that are either in the resolved state or that can be moved into the resolved state at the same time as the current bundle.
All of the required bundles are either in the resolved state or can be resolved at the same time as the current bundle.
![[Important]](imagesdb/important.gif) | Important |
|---|---|
All of an application's bundles must be in the resolved state before the application can be started. |
If, at any time, any of the above conditions ceases to be satisfied, the bundle is moved back into the installed state. For example, this can happen if a bundle containing an imported package is removed from the container.
Starting — The starting state is a
transitory state between the resolved state and the active state. When a bundle is
started, the container must create the resources for the bundle. The container also
calls the start() method of the bundle's bundle activator
if one is provided.
Active — Bundles in the active state are available to do work. What a bundle does in the active state depends on the contents of the bundle. For a bundle containing a JAX-WS service provider, this means the service is available to accept requests.
Stopping — The stopping state is a
transitory state between the active state and the resolved state. When a bundle is
stopped, the container must clean up the resources for the bundle. The container
also calls the stop() method of the bundle's bundle
activator if one is provided.
Uninstalled — When a bundle is uninstalled it is moved from the resolved state to the uninstalled state. A bundle in this state cannot be transitioned back into the resolved state or any other state. It must be explicitly re-installed.
The most important lifecycle states for application developers are the starting state and the stopping state. The endpoints exposed by your application must be published during in the starting state. The published endpoints must be stopped during the stopping state.
The osgi subshell of the FUSE ESB Kernel console provides commands
for managing the OSGi runtime, including listing OSGi bundles and services and
managing bundle lifecycles. See the OSGi Console Commands in
| |  | |
 |
