The Start Level Service on the OSGi framework allows just that the idea is to assign a "bundle start level" to each bundle, a non-negative number, and to be able to change the "active start level" in a stepwise manner in order to control which group of bundles are active at that time.

The Start Level Service also allows setting an initial bundle start level to be assigned to newly installed bundles. The default bundle start level is 1. This level can be changed by either issuing a command to change it (we'll cover this command in Chapter 3, Felix Gogo) or by changing it in the framework configuration. In Felix, the configuration property to set the initial bundle start level is:

felix.startlevel.bundle=1

Change this property in conf/config.properties of the installed distribution.

For example, in the following diagram, we have a Felix instance with an additional three bundles installed (bundles A, B, and C). In this example, the installed bundles are given start level 2 and Bundle C is not started.

The start level 0 is assigned to the System Bundle, no other bundle is allowed on that start level, and the bundles provided with the Felix distribution are on start level 1.

When the framework is starting up, it will first have an active start level of 0, at which point the System Bundle is starting. Once this is done, it will go onto start level 1 and start all the bundles that were persistently marked for start. All bundles on a start level are started before going onto the next.

In the Chapter 3, we'll look at some of the Felix shell commands and learn how to check and change the active and bundle start levels.

In this example, if we change the framework's active start level, it will attempt to start Bundle A and Bundle B, and then set the active start level to 3.

Since Bundle C was not persistently marked as started (it's stopped), it will only be resolved.

By default, Felix will start up until active start level 1. To make it set a different active start level on startup, change the configuration entry that sets the beginning start level; for example, to set it to 3, you would add a property in conf/config.properties as such:

org.osgi.framework.startlevel.beginning=3

As mentioned previously, there are cases where grouping the start of bundles into distinct steps can be useful.

For example, in development scenarios, one may want to split the bundles into "Validated" and "Under Test" and assign those the start levels of 2 and 3 respectively. This would allow separating bundles that may cause issues from the others and control their startup more closely.

In other situations, when the start-up time is lengthy, a splash screen bundle may be placed on start level 1 and would only be removed when all bundles are started.

In our case, we will separate the bundles from a functional point of view. Those bundles are assigned start levels that simplify the operational and support activities needed to maintain the application:

This diagram does not contain all the bundles that will be used for this case study: some of them have been hidden to reduce clutter.

The start levels that we'll use to organize the bundles in our study are as follows:

For example, when going through a data migration or cleansing activity; the active start level is set to 2, which keeps only the inventory bundles active and stops the ones on higher start levels.

In the case where web-server maintenance is required, going down to active start level 3 is enough.