[configuration] problems with commas in string properties

[Basil James Whitehouse III <ja...@ingenura.com>]

I've been using a commons-configuration nightly build from February 15, 
2004 rather successfully.  Recently I have run into a problem with 
strings containing a comma "," in them.

I'm using XML to store properties, here's an example of the XML that is 
causing me grief.

<configuration>
    <message-text>A message, with a comma.</message-text>
<configuration>

When I use .getString( "message-text" ) the resulting property value is 
"A message", whereas I expected the full string.  If the comma is 
escaped (\,) then the resulting value is as expected ("A message, with a 
comma.").  While escaping a string isn't that difficult, nor uncommon, 
for a developer, it's not something I'd want the lay person to have to 
do, and it's easy to forget that it needs to be escaped.  BTW:  this 
particular bit of configuration is going to be done by an average user 
who is competent with XML structures, but not much beyond that.

 From looking at the source I figured out that the comma is used to 
create a List, and I could in fact recreate the text (if the comma is 
not escaped) by running though the list and adding back in the commas.  
While I've only glanced at the source, this doesn't seem like the best 
approach since if the token changes in the future, or there are 
additional tokens added (like a semi-colon), then I'd have to figure out 
what token was used.  It also seems like a List would be returned if the 
same property was defined twice in the same file, which I wouldn't be 
able to tell the difference that and a string with a comma in it.  As 
well right now I'm going to assume that there's only going to be one 
message, but I can think of future cases where I might find multiple 
property definitions handy, but also want a string with commas in it, in 
the same file.

So I guess my question is, can this behavior be changed?  If .getString 
is used could it return the whole string for the given property, and if 
.getList was used could it parse the property then and give it back as a 
List?

Looking at the source I think I've found the bit that does the string 
parsing, AbstractConfiguration.addProperty calls processString which 
parses out a List based on commas.  My cursory glance made me think that 
processString could be called in getList, and hence getString would 
return the complete string, but since I don't know how multiple 
properties with the same name (thus creating a list) are represented 
this may not be a correct guess.  I don't presume to know all the 
details of the source, nor driving factors to make these decisions, so 
take my code commentary with some salt, but please consider this feature 
request.

Let me know if I can provide any other information, I'd even be willing 
to create a test case to support this feature.

Responses to my email would be appreciated since I'm not subscribed to 
the list.

Thanks,
Jamie.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [configuration] problems with commas in string properties

[Emmanuel Bourg <eb...@micropole-univers.com>]

Eric Pugh wrote:

> setListDelimiter(null) // no delimiter
> setListDelimiter(";") // change it to ";"

What about enabling it by default for PropertiesConfiguration and 
disabling it for the other configurations ? We will have to add a 
delimiter property to the xml format read by the ConfigurationFactory. 
Something like :

<configuration>
   <properties fileName="project.properties">
     <list-delimiter>;</list-delimiter>
   </properties>
</configuration>

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

RE: [configuration] problems with commas in string properties

[Eric Pugh <ep...@upstate.com>]

Basil,

Excellently written email!  If you look at some of the posts to
[configuration] over the past two weeks, you'll see us discussing this.  In
a nutshell, different implementations of Configuration dealt with things
differently.  We made some changes to use AbstractConfiguration, which meant
the "," issue came to the fore front for some of the configurations.

I am somewhat loath to change the specification for .properties file prior
to 1.0.  The reason being that the main codebase for Configuration came from
Turbine and Fulcrum, where there are MANY users who have configurations set
up using:

my.list=a,b,c

However, I agree, that I think that the right way is
my.list=a
my.list=b

So, what I am going to suggest, for a 1.0 release of Configuration (which is
blocking the 1.0 release for Fulcrum and 2.4 release for Turbine) is that we
keep the "," logic the way it is, but add the ability to change what the
"list delimiter" is.  So you can say:

setListDelimiter(null) // no delimiter
setListDelimiter(";") // change it to ";"

Then when 1.0 is released, we can then start changing the API.  There are a
lot of good ideas for the future of [configuration], but we need to release
what we have...

Eric

> -----Original Message-----
> From: Basil James Whitehouse III
> [mailto:jamie.whitehouse@ingenura.com]
> Sent: Sunday, February 29, 2004 3:23 PM
> To: commons-dev@jakarta.apache.org; commons-user@jakarta.apache.org
> Subject: [configuration] problems with commas in string properties
>
>
> I've been using a commons-configuration nightly build from
> February 15,
> 2004 rather successfully.  Recently I have run into a problem with
> strings containing a comma "," in them.
>
> I'm using XML to store properties, here's an example of the
> XML that is
> causing me grief.
>
> <configuration>
>     <message-text>A message, with a comma.</message-text>
> <configuration>
>
> When I use .getString( "message-text" ) the resulting
> property value is
> "A message", whereas I expected the full string.  If the comma is
> escaped (\,) then the resulting value is as expected ("A
> message, with a
> comma.").  While escaping a string isn't that difficult, nor
> uncommon,
> for a developer, it's not something I'd want the lay person
> to have to
> do, and it's easy to forget that it needs to be escaped.  BTW:  this
> particular bit of configuration is going to be done by an
> average user
> who is competent with XML structures, but not much beyond that.
>
>  From looking at the source I figured out that the comma is used to
> create a List, and I could in fact recreate the text (if the comma is
> not escaped) by running though the list and adding back in
> the commas.
> While I've only glanced at the source, this doesn't seem like
> the best
> approach since if the token changes in the future, or there are
> additional tokens added (like a semi-colon), then I'd have to
> figure out
> what token was used.  It also seems like a List would be
> returned if the
> same property was defined twice in the same file, which I wouldn't be
> able to tell the difference that and a string with a comma in it.  As
> well right now I'm going to assume that there's only going to be one
> message, but I can think of future cases where I might find multiple
> property definitions handy, but also want a string with
> commas in it, in
> the same file.
>
> So I guess my question is, can this behavior be changed?  If
> .getString
> is used could it return the whole string for the given
> property, and if
> .getList was used could it parse the property then and give
> it back as a
> List?
>
> Looking at the source I think I've found the bit that does the string
> parsing, AbstractConfiguration.addProperty calls processString which
> parses out a List based on commas.  My cursory glance made me
> think that
> processString could be called in getList, and hence getString would
> return the complete string, but since I don't know how multiple
> properties with the same name (thus creating a list) are represented
> this may not be a correct guess.  I don't presume to know all the
> details of the source, nor driving factors to make these
> decisions, so
> take my code commentary with some salt, but please consider
> this feature
> request.
>
> Let me know if I can provide any other information, I'd even
> be willing
> to create a test case to support this feature.
>
> Responses to my email would be appreciated since I'm not
> subscribed to
> the list.
>
> Thanks,
> Jamie.
>
> ---------------------------------------------------------------------
> 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: [configuration] problems with commas in string properties

[Henri Yandell <ba...@generationjava.com>]

Agreed. I've found that repeated elements are the best way to do a list.
[to commons-config developers]

So in .properties:

foo.name=fred
foo.name=jim

creates a List

In .xml:

<foo>
  <name>fred</name>
  <name>jim</name>
</foo>

Though I do currently have a problem with:

...
  <foo><name>fred</name></foo>
  <foo><name>jim</name></foo>
...

as it puts them in the same list, rather than understanding some kind of
hierarchical concept, which might not be easy to even specify in a
.properties file.

Hen

On Sun, 29 Feb 2004, Basil James Whitehouse III wrote:

> I've been using a commons-configuration nightly build from February 15,
> 2004 rather successfully.  Recently I have run into a problem with
> strings containing a comma "," in them.
>
> I'm using XML to store properties, here's an example of the XML that is
> causing me grief.
>
> <configuration>
>     <message-text>A message, with a comma.</message-text>
> <configuration>
>
> When I use .getString( "message-text" ) the resulting property value is
> "A message", whereas I expected the full string.  If the comma is
> escaped (\,) then the resulting value is as expected ("A message, with a
> comma.").  While escaping a string isn't that difficult, nor uncommon,
> for a developer, it's not something I'd want the lay person to have to
> do, and it's easy to forget that it needs to be escaped.  BTW:  this
> particular bit of configuration is going to be done by an average user
> who is competent with XML structures, but not much beyond that.
>
>  From looking at the source I figured out that the comma is used to
> create a List, and I could in fact recreate the text (if the comma is
> not escaped) by running though the list and adding back in the commas.
> While I've only glanced at the source, this doesn't seem like the best
> approach since if the token changes in the future, or there are
> additional tokens added (like a semi-colon), then I'd have to figure out
> what token was used.  It also seems like a List would be returned if the
> same property was defined twice in the same file, which I wouldn't be
> able to tell the difference that and a string with a comma in it.  As
> well right now I'm going to assume that there's only going to be one
> message, but I can think of future cases where I might find multiple
> property definitions handy, but also want a string with commas in it, in
> the same file.
>
> So I guess my question is, can this behavior be changed?  If .getString
> is used could it return the whole string for the given property, and if
> .getList was used could it parse the property then and give it back as a
> List?
>
> Looking at the source I think I've found the bit that does the string
> parsing, AbstractConfiguration.addProperty calls processString which
> parses out a List based on commas.  My cursory glance made me think that
> processString could be called in getList, and hence getString would
> return the complete string, but since I don't know how multiple
> properties with the same name (thus creating a list) are represented
> this may not be a correct guess.  I don't presume to know all the
> details of the source, nor driving factors to make these decisions, so
> take my code commentary with some salt, but please consider this feature
> request.
>
> Let me know if I can provide any other information, I'd even be willing
> to create a test case to support this feature.
>
> Responses to my email would be appreciated since I'm not subscribed to
> the list.
>
> Thanks,
> Jamie.
>
> ---------------------------------------------------------------------
> 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