Page History

...

A component has a lifecycle that controls when it is started or stopped. A bundle must be started before the DM Runtime can process its components. When the bundle is started, the DM Runtime will parse then parses a specific DependencyManager-Component manifest headersheader, which points to a list of descriptors defining describing all annotated components. Such descriptors are actually generated at compilation time, and annotation are not reflectively parsed at runtime. Only the descriptor is used to process the components. For each component, the DM Runtime first ensures that all dependencies are satisfied before activating it. Likewise, the component is deactivated when some of the required dependencies are not available anymore or when the bundle is stopped. Unless the bundle is stopped, components may be deactivated and reactivated, depending on the departure and arrival of required dependencies. The manager which is in charge of maintaining the state of components is implemented in the DM Runtime bundle (org.apache.felix.dm.runtime bundle).

...

1. Wait for all required dependencies to be available. When all required dependencies are available:
   • Instantiate the component.
   • Inject all required dependencies (on class fields using reflection, or by invoking callback methods).
   • Inject all optional dependencies defined on class fields, possibly with a NullObject if the dependency is not available.
   • Call the component init method (annotated with @Init). In the Init method, you are yet allowed to add some additional dependencies (but using the API). Alternatively, you can also configure some dependencies dynamically (explained later, in #Dynamic Dependency Configuration).
2. Wait for extra dependencies eventually optionally configured from the init() method.
3. If the component is not using the @LifecycleController annotation (detailed in the #Controlling the Lifecycle section), then:
   • Invoke the component start method (annotated with @Start).
   • Publish eventual some OSGi services (if the component provides some services).
   • Start tracking optional dependencies applied on method callbacks (useful for the whiteboard pattern). Notice that NullObject pattern is not applied to optional callback dependencies. In other words, if the dependency is not there, your callback won't be invoked at all. If you need the NullObject pattern, then apply optional dependencies on class fields, not on callback methods.
4. Else do nothing because  the component will trigger itself the startup using the lifecycle controller.

...

1. If the bundle is stopped or if some required dependencies are unavailable, or if the component is deactivated by a factorySet, then:
   • Unbind eventual optional dependencies (defined on callback methods). Notice that any optional dependency unavailability does not trigger the component deactivation:  the removed callbacks are just invoked, if declared in the annotation.
   • Invoke the stop method (annotated wit @Stop), and unregister eventual some OSGi services (if the components provides some services).
   • invoke destroy method (annotated with @Destroy).
   • invoke removed callbacks for required dependencies, if any.

...

Notice that properties returned by the Map takes take precedence over other properties, and may override some of them.