OSGi Configuration Admin and Plugin start ordering

The current ConfigurationAdmin specification can be found here:


One feature of this specification is the Configuration Plugin. An implementation can be used to participate in the configuration process. You can e.g. add new properties or modify existing properties for a configuration.

A use case could be to substitute credential information. Where the default configuration just contains placeholder values, the plugin can substitute these values by the real ones, that can come from a system property or environment variable. The following example will show how to do this.

Configurable Component

We use the Configurator to make the example more handy. So here is an example configuration:

An component that consumes this configuration can look like this:

We put all in one bundle named demo.cm. When running this example we end up with a print-out like this:

Configuration Plugin

Because we are not happy the value ENV.TEST, we want to replace that. The Configuration Admin specification has the Configuration Plugin for that. This is just an interface to be implemented and registered as a service.

To outline the behavior, we want to have that implementation in a different bundle that is named e.g. demo.cm.plugin

When we now starting our bundles demo.cm and the demo.cm.plugin we may end up with the final result:

WHAT? We expected something like:

Whats the problem?

YES, it is possible that the substitution doesn't work. To outline the problem I show two different run configuration in bndtools:

This configuration may not work:

whereas this configuration works:

The difference is the start ordering of the bundles. This is related to the dynamics in OSGi. The demo.cm as well as Configurator and ConfigAdmin bundle starting very early, just before the demo.cm.plugin bundle. Means that no plugin service is available when we consume the configuration in our ExampleComponent in the demo.cm bundle.

Apache Felix Configuration Admin

As of version 1.9.16 the Apache Felix Configuration Admin implementation contains a feature to deal with this situation. The corresponding entry in the Apache bug tracker is FELIX-6059.

What to do? At first the plugin needs a additional service property config.plugin.id:

The seconds thing is to add the framework property felix.cm.config.plugins with a comma separated list of plugins (config.plugin.id - values) to wait for, before activating the Configuration Admin instance.

We have to add this property to the previous non-working configuration:

Now we get the expected result:

Thanks to Carsten Ziegeler, who implemented that!

The forth-coming Condition Service will also be useful in such situation. Because start ordering should play a role in OSGi you will nevertheless need some conditions to activate a service or whatever. If you are interested, please read this blog post: