Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Development Tools >

Java Tip 135: Layer and compare property files

A utility for comparing and combining property files eases multilayer property file organization

By Paul E. Baclace, JavaWorld.com, 02/28/03

  • Print
  • Feedback
.
Property files offer an elegant solution for storing program settings loaded at runtime. The elegance comes from the hierarchical naming scheme, the ability to override settings on the command line, and the idea of default properties. Earlier generations of settings files like .rc (read command) or .ini (initialize) files lack these features. Default properties are underutilized, however, probably because good examples are rare and no tools support comparing and manipulation.

The problem with one big property file is that developers inevitably need conflicting settings, and the settings might significantly differ for coding, testing, and deployment. The most common way to express these conflicts, or shall I say, alternatives, is by including commented-out settings. But this strategy does not work well for automated builds, and writing comments about what part should be uncommented and why requires effort. Some try to solve this problem by creating many property files that have overlapping definitions, but this leads to the developer either editing many files to keep them consistent or enduring the inconsistencies as they crop up—both of which waste time. Another common way to accommodate differing properties is to set them on the command line, but this quickly grows messy, and who wants to commit messy start-up scripts to source code control to share usage examples?

With the PropDiff utility described here, not only can variants of large property files be compared with ease, but also the layering of property files can be used as an organizing principle that makes the early stages of implementation much smoother.

Layers

Property files can be loaded by instantiating a Properties object and then using the load(InputStream inStream) method. Then the getProperty(String key) method is used to search for the value associated with the given key. When a Properties object is instantiated with the Properties(Properties defaults) constructor, the given Properties defaults object is searched only when a particular property is not found. The defaults parameter allows multilayered property files of an arbitrary depth to chain together like a linked list.

For example, two layers can load like this:

     Properties defaultProps = new Properties();
    defaultProps.load(new FileInputStream("default.props"));
    Properties props = new Properties(defaultProps);
    props.load(new FileInputStream("installation.props"));
    String value = props.get("my.setting");


Notice that default properties load first because they are needed in the next layer's constructor. Strictly speaking, empty Properties objects could be chained together and then loaded in any order, but you should pass to a constructor as much state as possible so that objects are fully formed right from the start. For clarity, imagine the property layers stacking up so that the defaults are created earlier and thus deeper than other Properties that use the defaults.

Layers in WebLogic

BEA WebLogic introduced me to the concept of using property file layers to separate settings into three levels (listed in loading order, so deepest layer is first):

  • Print
  • Feedback

Resources