You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Wolfgang Hoschek <wh...@lbl.gov> on 2004/06/17 07:58:50 UTC
[commons-collections] [Patch] ExtendedProperties
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [commons-collections] [Patch] ExtendedProperties
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I have reworked these methods to hopefully solve the problem. I would be
most grateful if you, or anyone else using ExtendedProperties, could confirm
that the class on latest CVS still works correctly.
Stephen
----- Original Message -----
From: "Wolfgang Hoschek" <wh...@lbl.gov>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [commons-collections] [Patch] ExtendedProperties
Posted by Emmanuel Bourg <eb...@micropole-univers.com>.
Wolfgang Hoschek wrote:
> 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
I've added a test in [configuration] to cover this case, it seems the
bug was already fixed there.
> 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.
PropertiesConfiguration is no more complex than ExtendedProperties
actually, the usage is quite similar if you decide not to use the
ConfigurationFactory. In this case the dependencies are minimal,
PropertiesConfiguration only relies on [collections] which you already
use and [lang] which is a really basic and common dependency. Is this
too much ?
I think I'll document what package is required for each configuration
type, I admit the dependency page generated by Maven is quite
frightening currently :)
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org