Composing advanced features using OSGi Declarative Services
Simple features can be controlled using bundle activator classes and direct implementation of interfaces such as ManagedService and ServiceTracker. As relationships between bundles become more complex, it can be better to use facilities such as OSGi Declarative Services (DS) to decompose a feature into individual services. DS (sometimes known as the Service Component Runtime, or SCR) provides lifecycle and injection management of OSGi services.
Organize the feature logic as a set of declarative services has a number of advantages:
- Activation of the service (which includes loading the Java classes that provide the service) can be deferred until the service is used; allowing the server to start quickly and to keep resource use to a minimum.
- A reference to the service is placed into the service registry, even when the service has not been activated, so that dependencies on the service can be resolved.
- Dependencies on other services can be injected at runtime, and activation of the various services will be ordered based on such dependencies.
- A service can be deactivated and reactivated when its service properties change, if required.
Detailed information about use of OSGi Declarative Services is available from a number of online resources, including the OSGi Community Wiki.
This task provides simple descriptions of how to declare the services to DS, how to obtain references to other services, and how to manage configuration properties for each service.
Subtopics
- Declaring the services to OSGi Declarative Services
We can use a separate XML file to declare each service within a bundle.
- Enable a service to receive configuration data
To enable a service to receive configuration data, you associate the service with a persisted identity, and code the service to receive the data. We can also provide descriptions and default values for this data, and make the labels and descriptions available in several languages.
Parent topic: Develop a Liberty feature