Configuration Admin Service

THe The OSGi Componendium Configuration Admin Service specifies a service, which allows for easy management of configuration data for configurable components. Basicaly configuration is a list of name-value pairs. Configuration is managed by management applications by asking the Configuration Admin Service for such configuration. After updating the configuration, it is sent back to the Configuration Admin Service. The Configuration Admin Service is like a central hub, which cares for persisting this configuration and also for distributing the configuration to interested parties. One class of such parties are the components to be configured. These are registered as ManagedService services. There is also a notion of ManagedServiceFactory, which allows for multiple configurations of the same kind to be applied.

...

For a starter this page sets out to describe how you can create a component, which is interested in some configuration. As such this page is at its very beginning just highlighting the simplest of all cases: A single component being interested in its configuration.

ManagedService Example

Consider you have requirement for some configuration, say the line length of a pretty printer. You want to have this configurable through configuration admin.

...

After the call to update the Configuration Admin service persists the new configuration data and sends an update to the ManagedService registered with the service PID org.sample.PrettyPrinterConfigurator, which happens to be our PrettyPrinterConfigurator class as expected.

ManagedServiceFactory example

Registering a service as ManagedServiceFactory means that it will be able to receive several different configuration dictionaries; that's particularly useful when we want to create a Service Factory, that is, a service responsible for creating multiple instances of a specific service.

A ManagedServiceFactory service needs to implement the ManagedServiceFactory interface, as showed in the example.

public class SmsSenderFactory implements ManagedServiceFactory
{	
	Map existingServices = new HashMap();
	
	public void updated(String pid, Dictionary dictionary) throws ConfigurationException 
	{
		// invoked when a new configuration dictionary is assigned
		// to service 'pid'. 
		if (existingServices.containsKey(pid))  //the service already exists
		{
			MyService service = (MyService) existingServices.get(pid);
			service.configure(dictionary);
		}
		else //configuration dictionary for a new service
		{
			MyService service = createNewServiceInstance();
			service.configure(dictionary);
			existingServices.put(pid, service);
		}
	}
	
	public void deleted(String pid) 
	{
		// invoked when the service 'pid' is deleted
		existingServices.remove(pid);
	}

	public String getName() 
	{
		return "test.smssenderfactory";
	}
}

The example above shows that, differently from the ManagedService, the ManagedServiceFactory is designed to manage multiple instances of a service. In fact, the update method accept a pid and a Dictionary as arguments, thus allowing to associate a certain configuration dictionary to a particular service instance (identified by the pid).

Note also that the ManagedServiceFactory interface requires to implement (besides the getName method) a delete method: this method is invoked when the Configuration Admin Service asks the ManagedServiceFactory to delete a specific service instance.

The registration of a ManagedServiceFactory follows the same steps of the ManagedService example:

private ServiceRegistration factoryService;
public void start(BundleContext context) {
    Dictionary props = new Hashtable();
    props.put("service.pid", "test.smssenderfactory");
    factoryService = context.registerService(ManagedServiceFactory.class.getName(),
        new SmsSenderFactory(), props);
}
public void stop(BundleContext context) {
    if (factoryService != null) {
        factoryService.unregister();
        factoryService = null;
    }
}
...

Finally, using the ConfigurationAdmin interface, it is possible to send new or updated configuration dictionaries to the newly created ManagedServiceFactory:

public class Activator implements BundleActivator 
{   
    private List configurationList = new ArrayList();  
	 
    public void start(BundleContext bundleContext) throws Exception 
    {  
        ServiceReference configurationAdminReference = 
            bundleContext.getServiceReference(ConfigurationAdmin.class.getName());  
              
        if (configurationAdminReference != null) 
        {  
            ConfigurationAdmin confAdmin = (ConfigurationAdmin) bundleContext.getService(configurationAdminReference);  
              
            Configuration configuration = confAdmin.createFactoryConfiguration("test.smssenderfactory", null);  
            Dictionary properties = createServiceProperties();
            configuration.update(properties);  
              
            //Store in the configurationList the configuration object, the dictionary object
            //or configuration.getPid()  for future use  
            configurationList.add(configuration);  
        }  
    }   
}  

Apache Felix Implementation Details

The Apache Felix implementation of the Configuration Admin Service specification has a few specialities, which may be of interest when deploying it. These are described here.

Configuration Properties

The Apache Felix implementation is configurable with Framework properties. Here is a short table listing the properties. Please refer to the later sections for a description of these properties.

Logging

Logging goes to the OSGi LogService if such a service is registered int the OSGi framework. If no OSGi LogService is registered, the log output is directed to the Java platform standard error output (System.err).

...

Note: The felix.cm.loglevel property is ignored if an OSGi LogService is actually used for logging because it is then the responsibility of the LogService to limit the actual log output.

Configuration Files

By default the Apache Felix Configuration Admin Implementation stores the configuration data in the platform filesystem. The location of the configuration data can be configured with the felix.cm.dir framework property.

...