Este contenido no está disponible en el idioma seleccionado.
Chapter 7. Lifecycle Management
7.1. Bundle lifecycle states
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.
ImportantAll 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.
7.2. Installing and resolving bundles
When you install a bundle using the bundle: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 bundle:resolve command, as follows:
bundle:resolve 181
Where the argument (181, in this example) is the ID of the bundle you want to resolve.
7.3. Starting and stopping bundles
You can start one or more bundles (from either the installed or the resolved state) using the bundle:start command. For example, to start the bundles with IDs, 181, 185, and 186, enter the following console command:
bundle:start 181 185 186
You can stop one or more bundles using the bundle:stop command. For example, to stop the bundles with IDs, 181, 185, and 186, enter the following console command:
bundle: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 bundle:restart command. For example, to restart the bundles with IDs, 181, 185, and 186, enter the following console command:
bundle:restart 181 185 186
7.4. Bundle start level
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.
7.5. Specifying a bundle’s start level
Use the bundle:start-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:
bundle:start-level 181 70
7.6. System start level
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 system:start-level in the console, as follows:
karaf@root()> system:start-level Level 100
If you want to change the system start level, provide the new start level as an argument to the system:start-level command, as follows:
system:start-level 200
