About This Article : OSGi Configuration
OSGi is a Java-specific framework that improves the way that Java classes interact within a single JVM. It provides the following features:
- a modified Java classloader which provides fine-grained control over symbolic linking with other code in the same JVM;
- a central service registry for decoupling callers of an interface from the interface implementation;
- an enhanced version of the java.lang.SecurityManager (ConditionalPermissionAdmin);
- a large set of standardized optional services for things like loading configuration-files, publishing events, exposing Java servlets, etc.
This article provides some details about how the OSGi configuration system (part of item (4)) can be used. Unlike some of the other articles in this series on OSGi, this addresses just some “how to” topics rather than diving into the implementation.
For further information about OSGi in general, see:
The ConfigurationAdmin Service
This OSGi service simply manages a map of (property-name, property-value) pairs for each OSGi service. As each service is started up the ConfigurationAdmin service provides it with the matching configuration data; if the configuration data for a service changes while the application is running it can also notify the service of these changes. There are two different ways that this data can be exposed to a service; see below for further details.
The simplest source (persistent store) of configuration data is a file on disk; as each service is started up it the ConfigurationAdmin service provides it with the configuration data retrieved from the appropriate file. However configuration data could theoretically come from LDAP, a database table, or any other source.
A service can explicitly update the configuration of some other service by using methods on the ConfigurationAdmin service directly. This can be usefully triggered from user interface actions, eg users clicking buttons or moving sliders may cause code to be executed which updates the configuration settings of some other service via the ConfigurationAdmin services’ API.
It is also possible to create configuration entries via the API. Services can be configured (eg via Declarative Services) to sit in an “inactive” state until a suitable configuration object exists, ie creating configuration data via the ConfigurationAdmin API can indirectly trigger the instantiation and startup of OSGi services.
Obtaining Configuration Data via Injection
If any object published as a service via OSGi specifies an interface-type of ManagedService then the ConfigurationAdmin service will detect it (the Whiteboard pattern) and pass the current configuration data to it via methods defined on that interface. This is definitely the easiest way for a service to get access to service-specific configuration data.
Obtaining Configuration Data via Lookup
Obtaining the ConfigurationAdmin service can be done in the standard manner for any OSGi service, ie use the BundleContext to get a ServiceReference, and then obtain the actual service - or use one of the declarative services approaches to inject a reference to the service. Methods on the ConfigurationAdmin interface can then be used to explicitly fetch the configuration settings.
Reading Configuration Files from Disk
The OSGi specification does not address where the ConfigurationAdmin service might get its configuration data from; that is considered an implementation-specific detail. In Apache ServiceMix configuration data is simply read from *.properties
files in the ${servicemix}/etc
directory. If configuration data is updated via an OSGi console tool or via application code invoking the ConfigurationAdmin APIs then these properties files are automatically modified.
Other OSGi environments are likely to have similar systems for initialising configuration from files on disk.