- Using XML for configuration
- Component Configuration in J2EE
- Component Configuration using the Preferences API
- A Common CCI architecture
- Conclusions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Component Configuration using the Preferences API
The stated goal of the Preferences API 2 aligns perfectly with the spirit of this article. The Preferences FAQ begins by saying
It is intended to replace most common uses of Properties, rectifying many of its deficiencies, while retaining its light weight. When using Properties, the programmer must explicitly specify a pathname for each properties file, but there is no standard location or naming convention. Properties files are "brittle", as they are hand-editable but easily corrupted by careless editing. Support for non-string data types in properties is non-existent. Properties cannot easily be used with a persistence mechanism other than the file system. In sum, the Properties facility does not scale.
However, the approach taken in the Preferences API is exactly the opposite of the approach taken in this essary. This essay calls for XML files and a standard lookup mechanism--basically a descriptor-up approach, working from the configuration data toward the Java application. The Preferences API takes a Java-down approach, emphasizing the API that configuration information should present to the developer and leaving the backing store as an implementation detail. The advantage of the Java-down approach is that the Preferences API should be compatible with a variety of different backing stores.
Like properties files, Preferences store name/value pairs as strings. However, the Preferences API includes several substantial improvements over properties files:
The Preferences API provides built-in helper methods to convert from strings to other primitive data types. It is also possible to store serialized Java objects for more complex data types.
From the developer's point of view, lookup and spatial scope are well-defined. There is no need to know anything where preference information is actually stored. The API allows you to ask for either user or system settings, scoped to a specific package. Behind the scenes, this information may be stored in flat files, XML files, a database, or anything else the Preferences provider can dream up.
The Properties API supports export from and import to a standard XML format. This makes property administration accessible to XML-based tools, even if the backing store does not use XML.
Here is a simple example that shows using the Properties API to obtain package-specific settings for a hypothetical game:
package com.develop.comet;
import
java.util.prefs.Preferences;
public class GetConfig
{
static Preferences packagePrefs =
Preferences.userNodeForPackage(GetConfig.class);
static
public String getMultiplayerURL() {
return
packagePrefs.get("multiplayerURL",
"http://www.develop.com");
}
static public int getHighScore()
{
return packagePrefs.getInt("highScore",
0);
}
}
There are several points worthy of note here:
The developer does not need to specify anything but a package or class name--the Preferences API handles the details of locating the information.
The static method userNodeForPackage interacts with a pluggable provider. On my test machine, this provider defaults to use the Windows Registry, but other providers can be plugged in without changing the code.
The get methods shown here support String and int types. Other choices are possible, including a byte array for arbitrary complex data.
The Preferences API is an enormous improvement over using Properties, and is certainly preferable if those are the only two choices available. However, the Preferences API still has some issues:
The Preferences API is designed with the client side in mind. This is obvious in its stated emphasis on being lightweight. Also, the Preferences API defines scopes that are appropriate for the client: user and system. By contrast, server side scopes might include server farms, applications, components, and roles. As a result of this client-side emphasis, the Preferences API does not integrate with XML-based J2EE configuration and cannot easily be used as an API to access J2EE deployment descriptors. Therefore, most J2EE developers will have to work with two disparate systems: the Preferences API and J2EE container configuration.
The Preferences API does not provide any standards for configuration metadata. Therefore, it is impossible for a generic tool to enumerate a component's valid configuration settings. This is a step backwards from J2EE configuration, which uses DTDs to at least partially specify the CCI.
The Preferences API is read/write. This does not map well to configuration in general, where write access is often unavailable and/or undesirable.
In fairness to the designers of the Preferences API, it was their explicit goal to create a lightweight solution. The question we must consider, then, is can the Preferences API (or something like it) seamlessly grow into something more heavyweight like the J2EE deployment descriptors?