This is the "classic" Properties loader which loads the values from a single or multiple files (which can be chained with "include =". All given path references are either absolute or relative to the file name supplied in the constructor.
In this class, empty PropertyConfigurations can be built, properties added and later saved. include statements are (obviously) not supported if you don't construct a PropertyConfiguration from a file.
The properties file syntax is explained here, basically it follows the syntax of the stream parsed by {@link java.util.Properties#load} andadds several useful extensions:
- Each property has the syntax
key <separator> value. The separators accepted are {@code '='}, {@code ':'} and any whitespace character. Examples: key1 = value1 key2 : value2 key3 value3
- The key may use any character, separators must be escaped:
key\:foo = bar
- value may be separated on different lines if a backslash is placed at the end of the line that continues below.
- The list delimiter facilities provided by {@link AbstractConfiguration}are supported, too. If an appropriate {@link ListDelimiterHandler} isset (for instance a {@link DefaultListDelimiterHandler} object configuredwith a comma as delimiter character), value can contain value delimiters and will then be interpreted as a list of tokens. So the following property definition
key = This property, has multiple, values
will result in a property with three values. You can change the handling of delimiters using the {@link AbstractConfiguration#setListDelimiterHandler(ListDelimiterHandler)}method. Per default, list splitting is disabled. - Commas in each token are escaped placing a backslash right before the comma.
- If a key is used more than once, the values are appended like if they were on the same line separated with commas. Note: When the configuration file is written back to disk the associated {@link PropertiesConfigurationLayout} object (see below) willtry to preserve as much of the original format as possible, i.e. properties with multiple values defined on a single line will also be written back on a single line, and multiple occurrences of a single key will be written on multiple lines. If the {@code addProperty()} method was calledmultiple times for adding multiple values to a property, these properties will per default be written on multiple lines in the output file, too. Some options of the {@code PropertiesConfigurationLayout} class haveinfluence on that behavior.
- Blank lines and lines starting with character '#' or '!' are skipped.
- If a property is named "include" (or whatever is defined by setInclude() and getInclude() and the value of that property is the full path to a file on disk, that file will be included into the configuration. You can also pull in files relative to the parent configuration file. So if you have something like the following: include = additional.properties Then "additional.properties" is expected to be in the same directory as the parent configuration file. The properties in the included file are added to the parent configuration, they do not replace existing properties with the same key.
Here is an example of a valid extended properties file:
# lines starting with # are comments # This is the simplest property key = value # A long property may be separated on multiple lines longvalue = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa # This is a property with many tokens tokens_on_a_line = first token, second token # This sequence generates exactly the same result tokens_on_multiple_lines = first token tokens_on_multiple_lines = second token # commas may be escaped in tokens commas.escaped = Hi\, what'up? # properties can reference other properties base.prop = /base first.prop = ${base.prop}/first second.prop = ${first.prop}/second A {@code PropertiesConfiguration} object is associated with aninstance of the {@link PropertiesConfigurationLayout} class,which is responsible for storing the layout of the parsed properties file (i.e. empty lines, comments, and such things). The {@code getLayout()}method can be used to obtain this layout object. With {@code setLayout()}a new layout object can be set. This should be done before a properties file was loaded.
Like other {@code Configuration} implementations, this class uses a{@code Synchronizer} object to control concurrent access. By choosing asuitable implementation of the {@code Synchronizer} interface, an instancecan be made thread-safe or not. Note that access to most of the properties typically set through a builder is not protected by the {@code Synchronizer}. The intended usage is that these properties are set once at construction time through the builder and after that remain constant. If you wish to change such properties during life time of an instance, you have to use the {@code lock()} and {@code unlock()} methods manually to ensure thatother threads see your changes.
@see java.util.Properties#load
@author Stefano Mazzocchi
@author Jon S. Stevens
@author Dave Bryson
@author Geir Magnusson Jr.
@author Leon Messerschmidt
@author Kent Johnson
@author Daniel Rall
@author Ilkka Priha
@author Jason van Zyl
@author Martin Poeschl
@author Henning P. Schmiedehausen
@author Eric Pugh
@author Emmanuel Bourg
@version $Id: PropertiesConfiguration.java 1624601 2014-09-12 18:04:36Z oheger $