OSGi Alliance Blog: Easier Configuration Admin

We are likely to introduce a new service that makes Configuration Admin significantly easier to use. How? By using the Java type machine. Though properties are nice and flexible, they tend to cause cluttered code because of the required checks and conversions. The new model therefore defines configuration types with interfaces. For example, this is how a simple configuration type for a web service would look like:

package com.acme.webconf;
public interface WebConf {
 int port();
 String host();
}

The PID is defined by the interface name, in this example it is com.acme.webconf.WebConf. This "record" has a port (an integer) and a host name (a String). A bundle that wants to receive this information, only has to register a Configurable<WebConf> service. For example:

 @Component
public Webserver implements Configurable<WebConf> {
 public void setup(WebConf conf ) {
   web( conf.port(), conf.host() );
 }
 public void deleted(WebConf conf) {
   stop();
 }
}

No more type error prone type conversions, no more spelling errors in property names or PIDs! And you're not restricted to a single PID, you can extend the interfaces with other interfaces and each extended interface name will automatically be used as PID, merging all underlying configuration records. Annotations in this specification will also make data validation easier.

It is also possible to use factories. In that case, register a ConfigurableFactory, which looks like:

 public interface ConfigurableFactory<WebConf> {
  Configurable<WebConf> newInstance();
  void noConfigurations();
}

This specification will make Configuration Admin significantly easier to use.

Peter Kriens

P.S. Did you already register for the community event?
P.S. And did you look at the Masterclass On OSGi (with certificate) in Girona?

John Conlon :

Excellent, plan for making it easier to use ConfigAdmin.

Was just experimenting with migrating away from ManagedServiceFactory(s) to Declarative Services and it's little know feature of providing similar interaction with ConfigAdmin. Hat tip to Neil's
http://njbartlett.name/2010/07/19/factory-components-in-ds.html

Now I just bundle my components with both a component.xml and a metatype.xml (allowing UIs to present dynamic configuration forms.)

Besides the changes to ConfigAdmin you mentioned will there also be changes to DS schema or the DS type based activation methods?

Philipp Kursawe :

@John: Do you already have a Metatype based UI builder ready? I always found th Metatype to limited for UI building. For instance it lacks a grouping feature to group similar features/properties together.

I wanted to create a JFace UI for ConfigAdmin but had no time so far.

Steve Siebert :

Have you considered leveraging existing type annotation bindings to support type safety? I found the Configuration Admin service to be too simplistic in terms of support for complex configuration and too much overhead, as your article suggests for type conversion. I developed my own configuration service api that supports both "bound" configurations (using either JAXB or JPA annotations) or properties, using a similar model for the OSGi Configuration Admin service. What I like about both the JAXB and JPA annotations is that not only does it support complex configurations (supports inheritance and aggregation relationships), but it also provides typing and direct serialization methods to XML or relational database, respectively. I've successfully created a few configurations where the configuration classes were annotated with both, and the configuration server and client were able to store the configuration either way.

I do like your approach, though, and I can see ways it would provide for backwards compatibility with the existing Configuration Admin service.

John Conlon :

@Phillip: Yes. While Steve mentions in his comment, a JAXB approach, I chose instead an OSGi Metatype/Config admin frontend and a backend implementation based on EMF and custom EMF Resources for loading metatype resources (not using the Metatype service, but the metatype.xml documents directly from the bundles). Display uses JFace Master Details Forms in EMF model editors. Saving these EMF resourses saves/updates the ConfigAdmin data. Configs can also be loaded and unloaded (export and importing) as pure metatype documents.

'lacks a grouping feature', - AFAIK (Peter correct me if this is wrong) the schema for metatype is extensible - if you wanted to, you could add the grouping elements in your metatype documents and use these as you please in your presentation.

BTW - There are some real gems in the OSGi Compendium, and I think metatype is one of them. I also use it to extend my EMF business domain model elements/UIs and as config spec and data in (autoconf.xml) documents within OSGi Deployment Admin scenarios.

@Steve: I have not done performance testing, what do you mean by overhead?

Andrej :

Where can I find some documentation about it's usage? What is the release version of this feature?

Thanks!

Easier Configuration Admin

2010-08-31

Comments

Registration Open

March 26 to 29 in Reston, VA, USA

Read the OSGi Blog ...

OSGi Alliance Restructures Membership, Promotes Broader Technical Participation

Publicly share ideas and information under OSGi Community Wiki

OSGi Alliance Slides Available

Slides Available