Hi,
I believe there is a bug in ExtendedProperties that causes the following config file to be parsed incorrectly on load(...):
allow.meta=a allow.meta=b, c, d
Here, props.getVector("allow.meta") yields a list where the first element is "a" and the second element is "b, c, d". Rather, it should yield a list with four elements: ["a, "b", "c", "d"]. As a patch I added string tokenizing code at the very beginning of addProperty that seems to fix the problem.
I tested this and thankfully it works fine now.
Thanks for looking into this, perhaps even before 3.1 goes final.
Here is the patch:
public void addProperty(String key, Object token) {
// begin patch added code WH
if (token instanceof String &&
((String) token).indexOf(PropertiesTokenizer.DELIMITER) > 0) {
PropertiesTokenizer tokenizer = new PropertiesTokenizer((String) token);
while (tokenizer.hasMoreTokens()) {
String value = tokenizer.nextToken(); /*
* We know this is a string, so make sure it
* just goes in rather than risking vectorization
* if it contains an escaped comma
*/
addProperty(key, unescape(value));
}
return;
}
// end patch WH Object obj = this.get(key);
... code here remains unchanged
}BTW, please don't deprecate ExtendedProperties and refer people to future Commons-Configuration.
The Commons-Configuration complexity and their dependencies are a big big mess for someone who simply and conveniently wants to read in some configuration values. ExtendedProperties is ideal for such purposes: It does the job in a single class and has zero dependencies.
Thanks, Wolfgang.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
