XMLConfiguration does not fully support disabled delimiter parsing

• Key: CONFIGURATION-268
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Oliver Heger
• Reporter: Oliver Heger
• Affects Version/s: 1.4
• Fix Version/s: 1.5

Description

A call to setDelimiterParsingDisabled(true) should completely turn off the mechanism for searching for list delimiters and splitting property values.

However XMLConfiguration.save() escapes list delimiters even in this mode. When later such a configuration file is loaded and delimiter parsing is turned off, the values of affected properties will contain the escape character.

Comments

[Oliver Heger]

Attributes are also affected, but here the situation is more complicated: We support multiple values for a single attribute, so somebody could do something like this:

XMLConfiguration conf = new XMLConfiguration();
conf.setDelimiterParsingDisabled(true);
conf.addProperty("test[@attr]", "1,2,3");
conf.addProperty("test[@attr]", "4,5,6");

If such a configuration is saved, our current implementation will produce the following element:
<test attr="1\,2\,3,4\,5\,6"/>
If this element is loaded when delimiter parsing is disabled, an attribute with two values is created, but the values contain the escaping character. (Note that this is not a problem when delimiters are enabled.)

I think if delimiter parsing is disabled, attribute values should be read as they are without doing any modifications like removing escape characters. They may be part of the real attribute value. But because XML does not allow multiple occurrences of a single attribute, we always need a delimiter character for representing multiple attribute values. Now when loading a configuration file and delimiter parsing is disabled, deciding whether a delimiter character is used is not trivial. What we could do is using an untypical delimiter character, e.g. the pipe. Then the example element would look like
<test attr="1,2,3|4,5,6"/>
If an attribute value contained this delimiter character, it would have to be escaped. But we still cannot be 100% sure whether the user in deed wants to define an attribute with the single value "1,2,3|4,5,6".

[Emmanuel Bourg]

And what about generating 2 elements ?

<test attr="1,2,3"/>
<test attr="4,5,6"/>

[Oliver Heger]

Adding new elements would change the indices of list elements in an almost unpredictable way. This could be quite confusing if keys with indices were used.

I think I will go for the solution with the special delimiter and add some notes to the Javadocs. I just found out that we do not support escaping the escape character itself (e.g. in <dirs value="C:\Temp\,C:\Progs\"> the backslash behind Temp would escape the list delimiter). Will try to fix this.

[Oliver Heger]

A fix was committed. There are also some more unit tests for the "pathological" cases with escaped and non escaped delimiter characters.

[Emmanuel Bourg]

That looks a bit weird to introduce a secondary list delimiter to disable the primary list delimiter. Why not letting the user change the delimiter himself ? We might add a note in the javadoc suggesting that setDelimiterParsingDisabled(true) is not recommended if list properties are used in attributes, and that changing the list delimiter to an untypical character is preferred.