Conclusions
I believe that the CCI design proposed here is a good first stab the design objectives stated above. To reiterate:
Simple key/value string settings are supported, as in today's Preferences API.
Structure is provided using XML. Type is implemented using XML Schema.
Lookup and scope are managed by pluggable named providers to the Preferences API. Legacy providers will often be read-only.
Because lookup and scope vary with different providers, deployers may need to learn multiple different schemes. This learning process is shortened by making diagnostic information available via printConfigurationTrace.
Metadata 3 is provided through the PreferencesMetadata interface. Developers have multiple options for exposing this information, including at least one that is based on static analysis of code.
All of the features of the existing Preferences API and J2EE deployment descriptors are preserved.
All of the features listed above are pay-as-you-go.
This approach requires only minimal new code: factory methods and printConfigurationTrace methods for each different form of CCI.\
All existing Java code will continue to work as-is. However, switching to use of the Preferences API will provide additional benefits such as PreferencesMetadata and printConfigurationTrace..