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