Bundle and lifecycle interactions

The module layer defines bundles and uses OSGi modularity features. The lifecycle layer uses OSGi framework to manage and execute bundles. It provides bundles with a management API and a lifecycle at runtime.
Outside the application, the lifecycle layer provides operations for the bundles through the lifecycle API.
Inside, it defines how bundles accesss their execution context.

Through the lifecycle API, a management application or an administrator can install/stop/start/update/refresh bundles to modify the application configuration. Bundles themselves can use the lifecyle API to modify their own configuration.

1. Bundle cache
OSGi framework provides a persistent bundle cache, which allows to reinstall and start the bundles that were installed at shutdown on the next framework startup. It can be seen as the deployed configuration of the application.

When started, cached bundles are marked as so. When the framework is restarted, cached bundles are reinstalled, and those marked as started are automatically started.

2. Bundle properties
Through its context, a bundle can access some properties. Theses properties can be defined either in the bundle context, or in system properties.
A call to context.getProperty("foo") searches first in the bundle context properties, then in the system properties. It eventually returns null if the property could not be found.

3. Threading
The OSGi framework heavily relies on java threads. It does not manage concurrency, but offers some guarantees. For example, it guarantees that the stop() method of a bundle activator will not be called before its start() method returns.

4. Persisting bundle state
There is only one instance of a bundle's activator between the calls of its start() and stop() methods. When the bundle is restarted, a new instance is created. This means there is no way to persist a bundle state between two starts of a bundle.

To persist a state, one has the following options :

1. store the state in a database or a file;