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, and once they are resolved, bundles move to the resolved 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 they 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 any of the above conditions ceases to be satisfied, the bundle is moved back into the installed state. For example, this can happen when a bundle that contains 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 when 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 example, a bundle containing a JAX-WS service provider indicates that 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 when 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 an application are published during the starting state. The published endpoints are stopped during the stopping state.
When you install a bundle using the osgi:install command (without the
-s flag), the kernel installs the specified bundle and attempts to
put it into the resolved state. If the resolution of the bundle fails for some
reason (for example, if one of its dependencies is unsatisfied), the kernel leaves
the bundle in the installed state.
At a later time (for example, after you have installed missing dependencies) you
can attempt to move the bundle into the resolved state by invoking the
osgi:resolve command, as follows:
osgi:resolve 181
Where the argument (181, in this example) is the ID of the bundle you
want to resolve.
You can start one or more bundles (from either the installed or the resolved
state) using the osgi:start command. For example, to start the bundles
with IDs, 181, 185, and 186, enter the following console command:
osgi:start 181 185 186
You can stop one or more bundles using the osgi:stop command. For
example, to stop the bundles with IDs, 181, 185, and 186, enter the following
console command:
osgi:stop 181 185 186
You can restart one or more bundles (that is, moving from the started state to the
resolved state, and then back again to the started state) using the
osgi:restart command. For example, to restart the bundles with IDs,
181, 185, and 186, enter the following console command:
osgi:restart 181 185 186
A start level is associated with every bundle. The start
level is a positive integer value that controls the order in which bundles are
activated/started. Bundles with a low start level are started before bundles with a
high start level. Hence, bundles with the start level, 1, are started
first and bundles belonging to the kernel tend to have lower start levels, because
they provide the prerequisites for running most other bundles.
Typically, the start level of user bundles is 60 or higher.
Use the osgi:bundle-level command to set the start level of a
particular bundle. For example, to configure the bundle with ID, 181,
to have a start level of 70, enter the following console
command:
osgi:bundle-level 70 181
The OSGi container itself has a start level associated with it and this system start level determines which bundles can be active and which cannot: only those bundles whose start level is less than or equal to the system start level can be active.
To discover the current system start level, enter osgi:start-level in
the console, as follows:
karaf@root> osgi:start-level Level 100
If you want to change the system start level, provide the new start level as an
argument to the osgi:start-level command, as follows:
osgi:start-level 200
 |  |  |
 |
