One of the services in the OSGi core specification is the start level service. Its name implies that you can use it to determine the order in which bundles start. However, there are a couple of caveats that you must take into account. But first, let’s start by looking at this service more closely.
If you’re familiar with the runlevels in Linux, they are a pretty good analogy. Start levels are assigned to bundles, and this is one of the responsibilities of the management agent. The framework itself also has a certain start level, and only bundles with a start level lower than or equal to that of the framework will actually be active. Bundles with a start level higher than that of the framework will not be active. You can however tell such a bundle to become active as soon as the framework reaches this start level. That’s usually described as “persistently started”.
When the framework starts up, it will go through the start levels one by one until it reaches the target start level. That means that by assigning start levels to bundles, you can determine their startup order. By the way, if multiple bundles share the same start level, there is no guarantee in what order they will start.
There are however two things to keep in mind:
- The start level service is optional and when it’s not present, you no longer have control over the startup order.
- Never ever depend on the presence of a service that was published by a bundle with a lower start level. Services are dynamic, they can come and go at any time. Typically, when a bundle is updated, its services go away for a short while. If you do not take this into account, you will run into problems when you actually start performing updates.
In other words, you must always be able to start your bundles in a random order, and this should never cause any problems. The worst case scenario is that the order is very inefficient, but it must never be the case that your application won’t start at all. This is something you must already test during development!
With that in mind, there are a couple of interesting applications for start levels:
- Diagnostics mode
A higher start level than normal that will active extra bundles that add monitoring or debugging functionality. The start level, as always, will be set by the management agent whenever something goes wrong that needs further analysis.
- Power save mode
For embedded applications, a special power save start level could disable all bundles that are not necessary in that mode. For example, if an application has a user interface, it could hide it in this mode.
- High priority features
Think about bundles that should really be started early in the startup process, such as a logging service, or a splash screen. By giving such bundles a low start level, you can start them as early as possible.
Summing it up, you can state that start levels can be used to determine the startup order of your application, but you can never rely on it when developing your bundles. Bundles should not know about or rely on them! If you keep that in mind, you can start using start levels in a good way!