commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wolfgang Hoschek <>
Subject [commons-collections] [Patch] ExtendedProperties
Date Thu, 17 Jun 2004 05:58:50 GMT

I believe there is a bug in ExtendedProperties that causes the 
following config file to be parsed incorrectly on load(...):

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));
	    // 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message