Home > Articles > Programming > Java

  • Print
  • + Share This
From the author of

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

  • + Share This
  • 🔖 Save To Your Account