http://today.java.net/pub/a/today/2003/10/10/configurationblues.html

My comments follow

I have always believed that the key to successful component development is a unified and simplified configuration service. The configuration service I have implemented for my server side java RAD product Aspire/J2EE is deemed so simple that I have never thought of publishing its design publicly thinking how small it is. Nevertheless I have explained it in smaller pieces at the following URLs.

1. Beginnings of a Flexible .NET Architecture: A Simplified Config Service. Although this article is geared towards .net, it is based on its original implementation in Aspire.

2. For Tomcat developers Aspire comes in a Jar. This article shows how an entire data access service is built using reusable components using the same configuration service

If architecture were to be the tower of babel, configuration is its language. This web log reflects the relationship between architecture and configuration

I am adding these entries here hoping that they will influence some future designs in configuration. With out delving into the above links, here is a brief over view

//There is a sense of application level services
IAppServices  interfaceToAppServices = SomeFactory.getAppServices();

//There is a sense of a configuration service
IConfig  interfaceToConfig = interfaceToAppServices.getConfig();

String key = "/scop1/scope2/scope3/key";
String defaultValue = "abc";

String value = interfaceToConfig.getValue(key, defaultValue);

And that's all there is to it. The idea is that configuration is an interface with a dictionary like semantics over a hierarchical data structure, that may or may not be chosen to represent in an XML Format. By leaving the implementation aside, one can use the following as implementation of IConfig

1. One properties file to hold the key value pairs
2. A collection of properties  to hold the key value pairs
3. One XML file to hold the key value pairs
4. A collection of of XML files to hold the key value pairs
5. A database to hold the key value pairs

For instance Aspire has started out with a simple single properties file implementing IConfig. Then the second release extended it to multiple files broken down to the convenience of the deployment. The third release gave the option of maintaining part of the configuration in a properties file and part in an xml file. The fourth release used multiple properties files and multiple xml files as the source of configurations. In all cases the client code never had to change. For the XML file representations that metadata can be published as XSDs which is quite external to the configuration.

By not tieing the hierarchical structure to the java classes, configuration can be kept closer to its domain which may be administration. I haven't thought about metadata as much as you have indicated but once the structure is deemed to be hierarchical it is not that hard to provide three levels of configuration apis to allow for simiplicity and growth. Example:

public interface IConfig
{
	String getValue(String key, default);
}
public interface IUpdatableConfig extends IConfig
{
	void putValue(String key, String value);
}

public interface IConfigMedataData {}

Configuration implementations can choose to implement these apis in a gradual manner