The property markup syntax is used to identify text in ASCII configuration files of a component as being configurable properties. These are modified automatically to match the component's configuration within the application before the component is started. All files identified in the cfgfiles array in a component are scanned for property markup and updated as needed each time the application is being prepared to start.
Note: The property markup is only supported for appliances that use the volfix configuration mode.
A configuration file is eligible for inserting property markup into it, if the file's syntax meets the following conditions:
The following file formats are known to comply with the above requirements, and are therefore instrumental:
To handle non-instrumental files, the recommended approach is to write a bash (or Perl) script that updates the config file on boot and instrument the script itself.
$$prop: val1 : name1 , val2 : name2 , ...
The presence of a $$prop: string on a line of text in the configuration file means that this line contains one or more property values. Usually, the $$prop: string and the rest of the line of text are made invisible to the application that uses this configuration file by making it appear as a comment (for example, if the configuration file is a Perl script this might look like:
$port = 3306 # $$prop: 3306:ip_port
The val:name pairs following the markup identifier string are interpreted as follows:
val1:name1 indicates that the first occurrence of the string val1 on this line is to be treated as the value of the property name1 and replaced whenever that property needs to be changed.
val2:name2 indicates that the first occurrence of the string val2 following the first occurrence of val1 is the value of the property name2.
etc.
If the name in a val:name pair is the string '-', the string val is simply ignored. This is used to skip parts of the configuration data that might otherwise match a property value, for example, a markup like this:
x1 = 1 # $$prop: 1:val
Causes the 1 in x1 to be considered the value of the property val. To make the string 1 that follows the = sign be the property value, the markup has to be:
x1 = 1 # $$prop: 1:-, 1:val
The special '-' property name is also used in case the property value is the empty string, for example, in the following markup the property is the empty string that follows the "x1 = " string:
x1 = #$$prop: "x1 = ":- , "":val
If a value contains punctuation characters that are part of the markup syntax (colon, comma, space), the value must be quoted, using the double-quote syntax that is defined for the ADL descriptor files.
$$propN: val1 : name1 , val2 : name2 , ... [$$]
This markup is used for configuration files that do not allow comment text to appear on the same line as the value that needs to be exposed as a modifiable property. It is similar to the inline syntax, but it indicates that the text on the line that follows the one on which the markup appears is to be searched for matching strings, not the current line.
$$propF: val1 : name1 , val2 : name2 , ... $$
This markup is used for configuration files in which the newline character is not considered different from other whitespace and updates of the file may cause newlines to be added or removed at any place where un-quoted whitespace occurs. For this type of markup, a closing $$ sequence is required to indicate the end of the list of val:name pairs. Newlines are allowed between the val:name pairs. All text following the closing $$ mark, regardless of newlines is searched for strings matching the values, until all values are found or until 1K of text is read for each val:name pair (if the latter occurs without finding all values, an error is reported). Each property value is still expected to reside on a single-line.
Some configuration files allow characters that have a special meaning (meta-characters) to be quoted in a way that they lose their special meaning and become part of normal data. The ADL property update code in the Volume Fixup utility is aware of quoting and will maintain it when property values are updated.
Whenever a property value contains such escaped characters, they must appear in the same exact way both in the markup (which is inside a comment section in the file) and in the actual text, even if these characters need to be escaped only in the normal config file text (or only in the comment). For example, the & character doesn't have a special meaning in HTML comments, but it has to be escaped in HTML data, that is:
<!-- $$propF "&":my_prop $$ --><sometag someattr="text & more text">
is not valid, even though "&" is okay to appear in the comment, and must be re-done this way:
<!-- $$propF "&":my_prop $$ --><sometag someattr="text & more text">
The quoting of the data values may be in different formats, depending on the file type, as specified by the quoting= attribute (see the component descriptor syntax). This quoting is independent of the C-style double quotes used by the markup syntax itself to enclose a property value - the latter is always done with the C-style double quotes and is superimposed on top of the former, for example, the string abc"def', which may be quoted as abc\"def for a C file, will appear as follows in the markup:
p = "abc\"def"; // $$prop "abc\\\"def":p_val
|
Copyright © 2012 CA.
All rights reserved.
|
|