@Retention(value=CLASS)
@Target(value=METHOD)
public @interface ConfigurationDependency
A configuration dependency is required by default, and allows you to depend on the availability of a valid configuration for your component. This dependency requires the OSGi Configuration Admin Service. Configuration Dependency callback is always invoked before any service dependency callbacks, and before init/start callbacks. The annotation can be applied on a callback method which accepts the following parameters:
In the following example, the Printer components depends on a configuration whose PID name is "sample.Printer". This service will initialize its ip/port number from the provided configuration.
package sample;
@Component
public class Printer {
@ConfigurationDependency(propagate=true) // Will use the fqdn of the Printer interface as the pid.
void updated(Dictionary cnf) {
if (cnf != null) {
String ip = cnf.get("address");
int port = Integer.parseInt(cnf.get("port"));
}
}
}
You can also define your own component properties using a custom type-safe interface:
package sample;
interface PrinterConfig {
String getAddress();
int getPort();
}
Next, we define our Printer service which depends on the PrinterConfig:
package sample;
@Component
public class Printer {
@ConfigurationDependency // Will use the fqdn of the PrinterConfig interface as the pid.
void updated(PrinterConfig cnf) {
if (cnf != null) {
String ip = cnf.getAddress();
int port = cnf.getPort();
}
}
}
In the above example, the updated callback accepts a type-safe configuration type (and its fqdn is used as the pid).
Configuration type is a new feature that allows you to specify an 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().
If the property contains a dot (which is invalid in java method names), then dots (".") can be converted using the following conventions:
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, it is returned as a proxy.
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}" "map.key1" => "value1", "map2.key2" => "value2"Map.
In case a lookup does not yield a value from the underlying map or dictionary, the following rules are applied:
Classes and enum values yield null;
| Modifier and Type | Optional Element and Description |
|---|---|
java.lang.String |
name
The name for this configuration dependency.
|
java.lang.String |
pid
Returns the pid for a given service (by default, the pid is the service class name, of the FQDN of
the configuration type found in the updated callback signature.
|
java.lang.Class<?> |
pidClass
Returns the pid from a class name.
|
boolean |
propagate
Returns true if the configuration properties must be published along with the service.
|
boolean |
required
Sets the required flag which determines if this configuration dependency is required or not.
|
public abstract java.lang.String pid
public abstract java.lang.Class<?> pidClass
public abstract boolean propagate
public abstract boolean required
public abstract java.lang.String name
Usage example of a Configuration dependency whose pid and propagate flag is configured dynamically from init method:
/**
* A Service that dynamically defines an extra dynamic configuration dependency from its init method.
*/
@Component
class X {
private Dictionary m_config;
// Inject initial Configuration (injected before any other required dependencies)
@ConfigurationDependency
void componentConfiguration(Dictionary config) {
// you must throw an exception if the configuration is not valid
m_config = config;
}
/**
* All unnamed dependencies are injected: we can now configure our dynamic configuration whose dependency name is "global".
*/
@Init
Map init() {
return new HashMap() {{
put("global.pid", m_config.get("globalConfig.pid"));
put("global.propagate", m_config.get("globalConfig.propagate"));
}};
}
// Injected after init, and dynamically configured by the init method.
@ConfigurationDependency(name="global")
void globalConfiguration(Dictionary globalConfig) {
// you must throw an exception if the configuration is not valid
}
/**
* All dependencies are injected and our service is now ready to be published.
*/
@Start
void start() {
}
}