If you had to name a single great thing about OSGi, it would probably be its dynamics. Services come and go; other services react to those events, configuration can change and so on. Even the startup is dynamic: start levels are increased synchronously; however, configuration, Declarative Services, and Blueprint are started asynchronously after bundles turn active. We love that but sometimes you want to exercise control over when your application is actually fully started or more importantly when it is not. You certainly do not want your system to be accessible with a security module that threw an exception during startup. Unlike monolithic applications, an OSGi application behaves more like a distributed system that converges to a final state eventually.
We will show you a way to monitor startup of your application by creatively using some common OSGi mechanisms and demonstrate failure scenarios for common subsystems like configuration and Blueprint. We will also demonstrate the concept of start phases which are a higher-level concept on top of OSGi start levels. A phased start enables a higher level of security in the face of failures during startup.
The source code for the APIs and the reference implementation are available under Apache 2.0 license