Add a value to the configuration, returning a new object.
Add a value to the configuration, returning a new object. If the option already exists in the specified section, it is replaced in the new configuration. Otherwise, it's added. If the section doesn't exist, it's created and the option is added.
Example:
val cfg = Configuration(...) val newCfg = cfg + ("myNewSection", "optionName", "value")
the section name
the option name
the value
a new Configuration
object with the change applied.
Add new sections to the configuration.
Add new sections to the configuration. Example usage:
val cfg = Configuration(...) val newCfg = cfg ++ Map( "newSection1" -> Map("option1" -> "value1", "option2" -> "value2"), "newSection2" -> Map("option1" -> "value1") )
A map of (section -> Map(option -> value)) values
new configuration
Add multiple (section -> (option -> value)) triplets to the configuration, returning the new configuration.
Add multiple (section -> (option -> value)) triplets to the configuration, returning the new configuration. Example use:
val cfg = Configuration(...) val newCfg = cfg ++ (("newSection1" -> ("option1" -> "value1")), ("newSection2" -> ("option1" -> "value1")), ("newSection1" -> ("option3" -> "value3")))
one or more (section -> (option -> value)) triplets
new configuration
Remove a value from the configuration, returning a new object.
Remove a value from the configuration, returning a new object. If the section or option don't exist, the original configuration is returned (not a copy). If the section and option exist, the option is removed. If the section is then empty, it's also removed.
the section name
the option name
a new Configuration
object with the change applied, or the
original configuration if the section or option weren't
there.
Remove multiple (section -> option) pairs from the configuration, returning the new configuration.
Remove multiple (section -> option) pairs from the configuration, returning the new configuration. Example use:
val cfg = Configuration(...) val newCfg = cfg -- (("newSection1" -> "option1"), ("newSection2" -> "option1"), ("newSection1" -> "option3"))
sequence of (section, option) pairs
new configuration
Get a value as an instance of specified type.
Get a value as an instance of specified type. This method retrieves the
value of an option from a section and, using the specified (or implicit)
converter, attempts to convert the option's to the specified type. If you
import grizzled.config.Configuration.Implicits._
, you'll bring implicit
converters for various common types into scope.
If safe
is true
(as defined when the Configuration
object is built),
substitutions of nonexistent variables will result in empty strings for
where the substitutions were specified (e.g., val${section1.notValid}
will result in the string "val"). If safe
is false
, substitutions
of nonexistent values will result in an error (i.e., a Left
result).
the desired type of the result
the section from which to retrieve the value
the name of the option whose value is to be returned
a ValueConverter
object that will handle the
actual conversion.
Left(error)
on conversion error. Right(None)
if not found.
Right(Some(value))
if found and converted.
Get a value as an instance of specified type.
Get a value as an instance of specified type. This method retrieves the
value of an option from a section and, using the specified (or implicit)
converter, attempts to convert the option's to the specified type. If you
import grizzled.config.Configuration.Implicits._
, you'll bring implicit
converters for various common types into scope.
the desired type of the result
the section from which to retrieve the value
the name of the option whose value is to be returned
a ValueConverter
object that will handle the
actual conversion.
None
if not found or not convertible, Some(value)
if found
and converted. If you want to distinguish between "not found" and
"cannot convert", use asEither()
.
Get a value as an instance of specified type.
Get a value as an instance of specified type. This method retrieves the
value of an option from a section and, using the specified (or implicit)
converter, attempts to convert the option's to the specified type. If you
import grizzled.config.Configuration.Implicits._
, you'll bring implicit
converters for various common types into scope.
If safe
is true
(as defined when the Configuration
object is built),
substitutions of nonexistent variables will result in empty strings for
where the substitutions were specified (e.g., val${section1.notValid}
will result in the string "val"). If safe
is false
, substitutions
of nonexistent values will result in an error (i.e., a Left
result).
the desired type of the result
the section from which to retrieve the value
the name of the option whose value is to be returned
a ValueConverter
object that will handle the
actual conversion.
Failure(error)
on conversion error. Success(None)
if not
found. Success(Some(value))
if found and converted.
Invoke a code block on each section whose name matches a regular expression.
Invoke a code block on each section whose name matches a regular expression.
the regular expression to match
the block of code to invoke with each section
Works like Map.get()
, returning Some(string)
if the value
is found, None
if not.
Works like Map.get()
, returning Some(string)
if the value
is found, None
if not. Does not throw exceptions.
the section name
the option name
Some(value)
if the section and option exist, None
if
either the section or option cannot be found.
Retrieve a value, splitting it into a list of strings.
Retrieve a value, splitting it into a list of strings.
Returns Some(list)
if the key is found, and None
otherwise.
the section name
the option name
separator regex to use. Default: [\s,]
Like get()
, except that this method returns an Either
, allowing
errors to be captured and processed.
Like get()
, except that this method returns an Either
, allowing
errors to be captured and processed.
NOTE: Prefer tryGet()
, as this method may eventually go away.
the section name
the option name
Left(error)
on error. Right(None)
if not found.
Right(Some(value))
if found and processed.
Works like Map.getOrElse()
, returning an option value or a
default, if the option has no value.
Works like Map.getOrElse()
, returning an option value or a
default, if the option has no value. Does not throw exceptions.
Calling this function is the same as:
get(sectionName, optionName).getOrElse(default)
the section name
the option name
the default value
The option's value if the section and option exist, the default if either the section or option cannot be found.
Get a section.
Get a section. Similar to Map.get
, this method returns Some(Section)
if the section exists, and None
if it does not.
the section to get
Some(Section)
or None
Determine whether the configuration contains a named section.
Determine whether the configuration contains a named section.
the new section's name
true
if the configuration has a section with that name,
false
otherwise
Return a sequence of sections whose name match matches a regular expression.
Return a sequence of sections whose name match matches a regular expression.
the regular expression to match
Get the list of option names.
Get the list of option names.
the section's name
a list of option names in that section. The iterator will be empty if the section doesn't exist.
Get all options in a section.
Get all options in a section.
the section name
a map of all options and their values for the section. If the section doesn't exist, an empty map is returned.
Get the list of section names.
Get the list of section names.
the section names, in a iterator
Like get()
, except that this method returns a Try
, allowing
errors to be captured and processed.
Like get()
, except that this method returns a Try
, allowing
errors to be captured and processed.
the section name
the option name
Failure(error)
on error. Success(None)
if not found.
Success(Some(value))
if found and processed.
An INI-style configuration file parser.
Configuration
implements an in-memory store for a configuration file whose syntax is reminiscent of classic Windows .INI files, though with many extensions.Syntax
A configuration file is broken into sections, and each section is introduced by a section name in brackets. For example:
Notes and caveats:
At least one section is required.
Sections may be empty.
It is an error to have any variable definitions before the first section header.
The section names "system" and "env" are reserved. They don't really exist, but they're used during variable substitution (see below) to substitute from
System.properties
and the environment, respectively.Section Name Syntax
There can be any amount of whitespace before and after the brackets in a section name; the whitespace is ignored. Section names may consist of alphanumeric characters and underscores. Anything else is not permitted.
Variable Syntax
Each section contains zero or more variable settings. Similar to a Java
Properties
file, the variables are specified as name/value pairs, separated by an equal sign ("=") or a colon (":"). Variable names are case-sensitive by default, though the case-sensitivity (and other aspects of the variable name) may be changed by subclassingConfiguration
and providing your own version of thetransformOptionName()
method. Variable names may contain alphanumerics, underscores, and hyphens (-). Variable values may contain anything at all. The parser ignores whitespace on either side of the "=" or ":"; that is, leading whitespace in the value is skipped. The way to include leading whitespace in a value is escape the whitespace characters with backslashes. (See below).Continuation Lines
Variable definitions may span multiple lines; each line to be continued must end with a backslash ("\") character, which escapes the meaning of the newline, causing it to be treated like a space character. The following line is treated as a logical continuation of the first line. Unlike Java properties files, however, leading whitespace is not removed from continued lines.
Only variable definition lines may be continued. Section header lines, comment lines (see below) and include directives (see below) cannot span multiple lines.
Expansions of Variable Values
The configuration parser preprocesses each variable's value, replacing embedded metacharacter sequences and substituting variable references. You can use backslashes to escape the special characters that the parser uses to recognize metacharacter and variable sequences; you can also use single quotes. See Suppressing Metacharacter Expansion and Variable Substitution, below, for more details.
Metacharacters
The parser recognizes Java-style ASCII escape sequences
\t
,\n
,\r
,\\
,\
(a backslash and a space), and\
u
xxxx are recognized and converted to single characters. Note that metacharacter expansion is performed before variable substitution.Variable Substitution
A variable value can interpolate the values of other variables, using a variable substitution syntax. The general form of a variable reference is
${sectionName.varName}
.sectionName
is the name of the section containing the variable to substitute; if omitted, it defaults to the current section.varName
is the name of the variable to substitute.If a variable reference specifies a section name, the referenced section must precede the current section. It is not possible to substitute the value of a variable in a section that occurs later in the file.
The section names "system" and "env" are reserved for special "pseudosections."
The "system" pseudosection is used to interpolate values from
System.properties
For instance,${system.user.home}
substitutes the value of theuser.home
system property (typically, the home directory of the user running the program). Similarly,${system.user.name}
substitutes the user's name.The "env" pseudosection is used to interpolate values from the environment. On UNIX systems, for instance,
${env.HOME}
substitutes user's home directory (and is, therefore, a synonym for${system.user.home}
. On some versions of Windows,${env.USERNAME}
will substitute the name of the user running the program. Note: On UNIX systems, environment variable names are typically case-sensitive; for instance,${env.USER}
and${env.user}
refer to different environment variables. On Windows systems, environment variable names are typically case-insensitive;${env.USERNAME}
and${env.username}
are equivalent.Notes and caveats:
Configuration
uses thegrizzled.string.template.UnixShellVariableSubstituter
class to do variable substitution, so it honors all the syntax conventions supported by that class.Variable substitutions are only permitted within variable values. They are ignored in variable names, section names, include directives and comments.
Variable substitution is performed after metacharacter expansion (so don't include metacharacter sequences in your variable names).
To include a literal "$" character in a variable value, escape it with a backslash, e.g., "
var=value with \$ dollar sign
"Suppressing Metacharacter Expansion and Variable Substitution
To prevent the parser from interpreting metacharacter sequences, variable substitutions and other special characters, use the "->" assignment operator, instead of ":" or "=".
For example, suppose you want to set variable "prompt" to the literal value "Enter value. To specify a newline, use \n." The following configuration file line will do the trick:
Similarly, to set variable "abc" to the literal string "${foo}" suppressing the parser's attempts to expand "${foo}" as a variable reference, you could use:
Note: It's also possible, though hairy, to escape the special meaning of special characters via the backslash character. For instance, you can escape the variable substitution lead-in character, '$', with a backslash. e.g., "\$". This technique is not recommended, however, because you have to double-escape any backslash characters that you want to be preserved literally. For instance, to get "\t", you must specify "\\\\t". To get a literal backslash, specify "\\\\". (Yes, that's four backslashes, just to get a single unescaped one.) This double-escaping is a regrettable side effect of how the configuration file parses variable values: It makes two separate passes over the value (one for metacharacter expansion and another for variable expansion). Each of those passes honors and processes backslash escapes. This problem would go away if the configuration file parser parsed both metacharacter sequences and variable substitutions itself, in one pass. It doesn't currently do that, because it uses the separate
grizzled.string.template.UnixShellStringTemplate
classgrizzled.GrizzledString.translateMetachars()
method to do the variable substitution and metacharacter translation. In general, you're better off just sticking with the "->" assignment operator.Includes
A special include directive permits inline inclusion of another configuration file. The include directive takes two forms:
For example:
If the include path is not a URL, and is not an absolute path, its location is relative to the file that's trying to include it.
The included file may contain any content that is valid for this parser. It may contain just variable definitions (i.e., the contents of a section, without the section header), or it may contain a complete configuration file, with individual sections. Since
Configuration
recognizes a variable syntax that is essentially identical to Java's properties file syntax, it's also legal to include a properties file, provided it's included within a valid section.Note: Attempting to include a file from itself, either directly or indirectly, will cause the parser to throw an exception.
Comments and Blank Lines
A comment line is a one whose first non-whitespace character is a "#". A blank line is a line containing no content, or one containing only white space. Blank lines and comments are ignored.
Caller-supplied Predefined Sections
Calling applications may supply predefined sections and options, in the form of a map. These sections may then be used by other sections, via variable references. The predefined sections are defined in a map of maps. The outer map is keyed by predefined section name. The inner maps consist of options and their values. For instance, to read a configuration file, giving it access to certain command line parameters, you could do something like this:
Note that contents of the configuration file can override the predefined sections.
Applications may also provide a "not found" function that is called to resolve options that are not found in the table. Such a function can be used to supply on-demand sections and values. For example, suppose you want to do something crazy, such as look up any not-found values in a database. (This is probably a very bad idea, but it makes a good example.) You might do something like this: