Tuesday, August 31, 2010

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:

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:

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:

5 comments:

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'shttp://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?

@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.

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.

@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?