XMLConfiguration: Can't disable attribute splitting

• Key: CONFIGURATION-335
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Oliver Heger
• Reporter: Sergey Vladimirov
• Component/s: Format
• Affects Version/s: 1.5
• Fix Version/s: 1.6

Description

My XML configuration has the following attribute:
<some-element some-attribute=" " />

But XML Configuration is trying to split this string and trims it after splitting. I don't need this behaviour, but setting setDelimiterParsingDisabled() just changing delimeter to "|" and not disables attribute trimming.

Need either to disable trimming/splitting if setDelimiterParsingDisabled() is set to TRUE (incompatible change), or add something like setParseAttributesAsIs() that will prevent attributes to be trimmed and splitted

Comments

[Sergey Vladimirov]

Or at least constructHierarchy() and processAttributes() methods should be protected - to enable extending/changing behaviour

[Sergey Vladimirov]

XMLNode class (member of XMLConfiguration) should be protected, as well as handleDelimiters(node, node) method.

It seems no one tried to extend this class before...

[Oliver Heger]

I think your request is not in line with the XML specification. Have a look at http://www.w3.org/TR/REC-xml/#AVNormalize where the concept of attribute normalization is defined.

What you can do is using the content of an element instead of an attribute. Recently support for the xml:space attribute was added to XMLConfiguration (see CONFIGURATION-307). If this attribute is set on an element, whitespace in its content will be preserved. However, the current version 1.5 does not contain this feature yet.

[Courtney B. Arnold]

FYI for anyone else who is encountering this bug. The parsing is not a delayed parsing. It begins parsing the document once you have used it's constructor. So the work around would be to construct an XMLConfiguration object without any parameters, use the setDelimiterParsingDisabled(true), then load the xml file. Like so:

File configurationFile = new File("test.xml");
XMLConfiguration configuration = new XMLConfiguration();
configuration.setDelimiterParsingDisabled(true);
configuration.load(configurationFile);

[Sergey Vladimirov]

Courtney,

setDelimiterParsingDisabled() doesn't work for XMLConfiguration - it just changing delimeter to "|"

Oliver,

It's my code - i want to specify any possible xml parsing option i need. It's okay if XMLConfiguration doesn't support such behaviour - then it should allow me to change it in subclass.

[Oliver Heger]

My point is that the problem you are facing with the definition of CR and LF sequences in attributes is not caused by any attribute trimming or splitting activities of XMLConfiguration. Rather the XML parser already performs attribute normalization and replaces your sequence by a single white space. So even if you had access to the corresponding methods in XMLConfiguration, it would not help you because the strings passed to these methods have already been modified by the parser.

[Oliver Heger]

This is not a problem of attribute splitting operations performed by XMLConfiguration. The attribute values have already been modified by the XML parser. So closing this issue as invalid.

[Sergey Vladimirov]

Oliver,

Is parser doing "|" splitting? I thought it was line 487 in XMLConfiguration:

/** Constant for the delimiter for multiple attribute values.*/
private static final char ATTR_VALUE_DELIMITER = '|';

.......
Iterator it = PropertyConverter.split(
attr.getValue(),
isDelimiterParsingDisabled() ? ATTR_VALUE_DELIMITER
: getListDelimiter()).iterator();

[Oliver Heger]

The parser is certainly not doing "|" splitting, but it trims whitespace. As I understand this ticket this is your original problem, isn't it?

[Sergey Vladimirov]

Both actually.

It called "Can't disable attribute splitting", so unable to disable splitting was main problen

[Oliver Heger]

So I was too quick when closing this ticket.

The attribute splitting functionality was added because there is a mismatch between the configuration API and the capabilities provided by XML: the configuration API allows adding multiple values to an attribute while XML only supports a single value. For instance, you can have something like this:

config.addProperty("element[@attr]", "value1");
config.addProperty("element[@attr]", "value2");

When storing such a configuration, how should the multiple values of the attribute be treated so that the file can be loaded again and the resulting configuration is not changed? Because the problem is inherent there is so far no possibility of switching off this feature.

It might make sense to introduce a flag for turning off this mechanism. Can you give an example (other than that with whitespace) where this attribute splitting functionality caused undesired behavior?

[Sergey Vladimirov]

Oliver,

The problem were found with regular expression. Regexp can contain both commas and "|" characters.
"[[some\, |other\, ]]"

For me switching off this mechanism should result in some limitation, but it's okay as far as program does know about it and not using multiple attribute values mechanism.

Sergey

[Oliver Heger]

XMLConfiguration now has a new property attributeSplittingDisabled. If set to true, the values of attributes are stored in exactly the way as they are returned by the XML parser, without further modification.

Note that this property must be set before the configuration is loaded. So the following pattern has to be used:

XMLConfiguration config = new XMLConfiguration();
config.setAttributeSplittingDisabled(true);
config.setFile(myConfigFile);
config.load();

This is analogous to the delimiterParsingDisabled property of AbstractConfiguration.

[Ralph Goers]

Was this applied to the experimental branch?

[Oliver Heger]

No, it was not. The implementation of attributes is different in the experimental branch: attributes are not represented as Nodes, but each node has a map of attributes. Currently there is no direct support for multiple values of an attribute. See also the NodeHandler interface, which defines only a setAttributeValue() and a getAttributeValue() method.

For the experimental branch it makes certainly sense to redesign the whole splitting mechanism. Looking back, it has caused us a lot of trouble, and I am wondering if it is worth the whole pain.

[Ralph Goers]

I don't understand. XMLConfiguration in the experimental branch has a method named processAttributes that splits the attribute into Nodes. I have a config file for DefaultConfigurationBuilder that requires a ',' in it and it doesn't work. I replaced the property converter call with List<String> values = Collections.singletonList(attr.getValue()); and my DefaultConfgurationBuilder test worked fine, but a whole bunch of other unit tests now fail because attribute splitting isn't supported.

I either need to add the option to the experimental branch or disable attribute splitting entirely, otherwise I can't commit my new code to the experimental branch. What would you prefer?

[Ralph Goers]

I added attribute splitting to the experimental branch. If we decide to not allow attribute splitting we can remove it.