Dependency Manager - Configuration Dependency

A configuration dependency is always required, and allows you to depend on the availability of a valid configuration for your component. Configuration dependency is required by default.

To define a configuration dependency, you need to use the ConfigurationDependency interface. This interface can be created using DependencyActivatorBase.createConfigurationDependency() or DependencyManager.createConfigurationDependency() methods.

The dependency injects by default the configuration in an "updated" callback which can accept the following parameters:

  • updated(Dictionary)

  • updated(Component, Dictionary)

  • updated(<ConfigurationType>)

  • updated(Component, <ConfigurationType>)

If you only specify a pid, by default the callback method name is assumed to be "updated".

Configuration types are a new feature that allows you to specify a Java interface that is implemented by DM and such interface is then injected to your callback instead of the actual Dictionary. Using such configuration interface provides a way for creating type-safe configurations from a actual Dictionary that is normally injected by Dependency Manager. The callback accepts in argument an interface that you have to provide, and DM will inject a proxy that converts method calls from your configuration-type to lookups in the actual map or dictionary. The results of these lookups are then converted to the expected return type of the invoked configuration method. As proxies are injected, no implementations of the desired configuration-type are necessary!

The lookups performed are based on the name of the method called on the configuration type. The method names are "mangled" to the following form: [lower case letter] [any valid character]*. Method names starting with get or is (JavaBean convention) are stripped from these prefixes. For example: given a dictionary with the key "foo" can be accessed from a configuration-type using the following method names: foo(), getFoo() and isFoo().

The return values supported are:

  • primitive types (or their object wrappers);

  • strings;

  • enums;

  • arrays of primitives/strings;

  • Collection types;

  • Map types;

  • Classes and interfaces.

When an interface is returned, it is treated equally to a configuration type, that is, a proxy is returned.

Arrays can be represented either as comma-separated values, optionally enclosed in square brackets. For example: [ a, b, c ] and a, b,c are both considered an array of length 3 with the values "a", "b" and "c". Alternatively, you can append the array index to the key in the dictionary to obtain the same: a dictionary with "arr.0" => "a", "arr.1" => "b", "arr.2" => "c" would result in the same array as the earlier examples.

Maps can be represented as single string values similarly as arrays, each value consisting of both the key and value separated by a dot. Optionally, the value can be enclosed in curly brackets. Similar to array, you can use the same dot notation using the keys. For example, a dictionary with:

map={key1.value1,key2.value2}

and a dictionary with:

map.key1=value1
map.key2=value2

result in the same map being returned. Instead of a map, you could also define an interface with the methods getKey1() and getKey2() and use that interface as return type instead of a Map.

In case a lookup does not yield a value from the underlying map or dictionary, the following rules are applied:

  • primitive types yield their default value, as defined by the Java Specification;

  • string, Classes and enum values yield null;

  • for arrays, collections and maps, an empty array/collection/map is returned;

  • for other interface types that are treated as configuration type a Null-object is returned.

Here is a component depends on a configuration:

public class ServiceImpl {
    void updated(Dictionary<String, Object> cnf) {
        if (cnf != null) {
            String addr = (String) cnf.get("address");
            int port = Integer.valueOf(cnf.get("port");
            ...
        }
    }
}

public class Activator extends DependencyActivatorBase {
    @Override
    public void init(BundleContext ctx, DependencyManager dm) throws Exception {
        dm.add(createComponent()
          .setImplementation(ServiceImpl.class)
          .add(createConfigurationDependency().setPid(ServiceImpl.class.getName()));
    }
}

Here is the same example, but a custom configuration type interface is used (by default, the FQDN of the configuration type is assumed to be the configuration pid):

public interface MyConfig {
    String getAddress();
    int getPort();
}

public class ServiceImpl {
    void modified(MyConfig cnf) {
        if (cnf != null) {
            String addr = cnf.getAddress();
            int port = cnf.getPort();
            ...
        }
    }
}

public class Activator extends DependencyActivatorBase {
    @Override
    public void init(BundleContext ctx, DependencyManager dm) throws Exception {
        dm.add(createComponent()
          .setImplementation(ServiceImpl.class)
          .add(createConfigurationDependency().setCallback("modified", MyConfig.class);
    }
}