-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify and improve parsing of the .properties file format #685
Comments
I found the following nice explanation of [The Java Properties File Format] in addition to java.util.Properties.load(java.io.Reader) : The Java Properties File FormatA Java style properties file contains key value pairs (properties) in a file with ISO-8859-1 encoding (code page 28591). The file usually has a “.properties” file extension and consists of a series of lines (terminated by CRLF or CR or LF) each a key value pair, a comment or a blank line. Leading whitespace (spaces, tabs ‘\t’, form feeds ‘\f’) are ignored at the start of any line – and a line that is empty or contains only whitespace is treated as blank and ignored. A line where the first non-whitespace character is a ‘#’ or ‘!’ is a comment line and the rest of the line is ignored. If the first non-whitespace character is not ‘#’ or ‘!’ then it is the start of a key. A key is all the characters up to the first whitespace or a key/value separator (‘=’ or ‘:’). The separator is optional. Any whitespace after the key or after the separator (if present) is ignored. The first non-whitespace character after the separator (or after the key if no separator) begins the value. The value may include whitespace, separators, or comment characters. The following special cases are defined:
Any Unicode character may be inserted in either key or value using the following escape:
Finally, longer lines can be broken by putting an escape at the very end of the line. Any leading space (unless escaped) is skipped at the beginning of the following line. Examples
All the above will result in the same key/value pair – key “a-key” and value “a-value”.
The above are two examples of comments. Yes, you can add comments to Java .properties files – so please do!
The above shows how to embed a space in a key – the key is “Hong Kong” and the value is “Near China”. Without the ‘\’ escape, the key is “Hong” and the value is “Kong = Near China” (it wouldn’t be the first time I’ve seen it done…).
An example of a long line split into two. |
According to the above article, I found white space at the start of a value is not escaped correctly by our implementation. TEST_F(PropertiesTestSuite, StoreTest) {
const char* propertiesFile = "resources-test/properties_out.txt";
celix_autoptr(celix_properties_t) properties = celix_properties_create();
celix_properties_set(properties, "keyA", " valueA");
celix_properties_set(properties, "keyB", "valueB");
celix_properties_store(properties, propertiesFile, nullptr);
celix_autoptr(celix_properties_t) properties2 = celix_properties_load(propertiesFile);
EXPECT_EQ(celix_properties_size(properties), celix_properties_size(properties2));
EXPECT_STREQ(celix_properties_get(properties, "keyA", ""), celix_properties_get(properties2, "keyA", ""));
EXPECT_STREQ(celix_properties_get(properties, "keyB", ""), celix_properties_get(properties2, "keyB", ""));
} |
Also: Rename the nested / flat encoding style flag.
Also improves several small issues based on review comments.
And some small improvements based on review comments
1. Avoid discarding valid configuration on properties creation error. 2. Fix leak on cache creation error.
Reopening this issue. Properties now support JSON, consequently, the MANIFEST can be updated to use JSON as well. This update should also eliminate the remaining custom key/value parsing in the current manifest parsing source code. |
Because of the refactored bundle archive and manifest the bundle revision is no longer needed.
|
Clarify and improve parsing of the .properties file format
Apache Celix uses a .properties file to store and read configurable - framework and bundle - parameters.
The Apache Celix .properties file format is based on the Java .properties file format.
There is no RFC or clear specification document for the Java .properties file format, but there is a wikipedia page https://en.wikipedia.org/wiki/.properties
.properties file example in the wikipedia:
Clarify Apache Celix .properties file format
Write down a specification for the Apache Celix .properties file format. This does not have to be formal (EBNF), but it should make it clear for users what is and is not possible with .properties files.
Refactor .properties file parsing
The current parsing of .properties file is not ideal (parsing can lead to many allocation) and this should be improved.
The
manifest_readFromStream
can be used as input for the refactoring.A possible choice could be to to support multiple key/value delimiters (
=
and:
) and then extract and extend themanifest_readFromStream
to be used in properties and manifest handling.Add support for typed property value format
Update the format so that storage of typed properties (bool, long, version, double) is also possible.
The text was updated successfully, but these errors were encountered: