You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Borut Bolčina <bo...@najdi.si> on 2005/11/20 17:20:16 UTC
[configuration] Unexpected behavior
Hi,
when having an attribute value with commas in XML configuration file,
this value gets splitted. An example:
<?xml version="1.0" encoding="UTF-8"?>
<questionnaire>
<set week="42" text="Questions for first week">
<question text="First question, something after comma."> <===
offending
<answers>
<answer>(I) 1.a</answer>
<answer correct="true">(I) 1.b</answer>
<answer>(I) 1.c</answer>
</answers>
</question>
<question text="Second question, which includes comma in the
sentence."> <=== offending
<answers>
<answer correct="true">(I) 2.a</answer>
<answer>(I) 2.b</answer>
<answer>(I) 2.c</answer>
</answers>
</question>
...
When calling this method
/**
* @return all questions from XML configuration file
*/
@SuppressWarnings("unchecked")
public Collection<String> getQuestions() {
String ofQuestions = "set.question[@text]";
return config.getList(ofQuestions);
}
the returned list contains *four* instead of two questions:
1.) First question
2.) something after comma
3.) Second question
4.) which includes comma in the sentence
Is this by design? I think this should not work this way.
Regards,
Borut
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [configuration] Unexpected behavior
Posted by Jörg Schaible <jo...@gmx.de>.
Oliver Heger wrote:
> Jorge Ferrer schrieb:
>> Hi,
>>
>> Just in case someone also applied the proposed woraround, I have found
>> an important secondary effect when calling getProperties() which
>> converts the configuration to a java.util.Properties instance: it uses
>> the CHARACTER_NEVER_USED to serialize every multi-valued property.
>>
>> As a result, I'm trying to implement a patch to allow disabling
>> DELIMITER parsing for certain configuration. I'm having difficulties
>> as currently the DELIMITER is common for all configurations of the
>> JVM. So I have to change that first to make it per configuration. If
>> I'm able to make it work I'll send a patch.
>>
> <snip/>
>
> Jorge,
>
> there is a Bugzilla ticket that covers this issue:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=35828
>
> You might want to have a look. A patch to solve this problem would be
> highly appreciated.
I've been bitten by this also this week having LDAP names in the
configuration. Problem is, that my component is also just a library and
will be used in enterprize apps with different wars and compoennts, that
also use c-c. So I cannot just go and set the delimiter to something else,
because I might break other components by chance.
In addition to the bugzilla description, would it make sense to have a mode
that turns off the list capability at all?
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [configuration] Unexpected behavior
Posted by Jorge Ferrer <jo...@gmail.com>.
Hi Oliver and Jörg,
I have attached a patch to bugzilla with my implementation of list
delimiter per configuration and list delimiter disabling. You can find
it here:
http://issues.apache.org/bugzilla/show_bug.cgi?id=35828
I've added some new tests. I would like to ask you to help me test
this implementation. If you find any bug, please send me a test case
that shows it and I'll fix it.
BTW, I've had an issue which I'm not sure how to solve: class
XMLConfiguration contains an static inner class called
XMLBuilderVisitor which needs to access the delimiter. Unfortunately
as it is static it cannot access the delimiter of the current
configuration. Do you think it should be changed to a non-static inner
class?
--
Cheers,
Jorge
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [configuration] Unexpected behavior
Posted by Jörg Schaible <jo...@gmx.de>.
Jorge Ferrer wrote:
> Thanks for pointing the bug Oliver, I'll do my best to try to solve it.
>
> Jörg, I'll also implement a method to disable parsing the delimiter
> when reading properties. Multiple values will still be allowed in
> properties files by setting the same property more that once in the
> same file. Also, the delimiter will still be used to serialize the
> multiple values to a String when converting the configuration to
> java.util.Properties. Does it make sense to you?
Fine. IMHO you will normally not use turned off delimiters and multiple
values with the same configuration anyway. You just cannot guarantee this,
if it is configured with static elements.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [configuration] Unexpected behavior
Posted by Jorge Ferrer <jo...@gmail.com>.
Thanks for pointing the bug Oliver, I'll do my best to try to solve it.
Jörg, I'll also implement a method to disable parsing the delimiter
when reading properties. Multiple values will still be allowed in
properties files by setting the same property more that once in the
same file. Also, the delimiter will still be used to serialize the
multiple values to a String when converting the configuration to
java.util.Properties. Does it make sense to you?
On 12/23/05, Oliver Heger <he...@med.uni-marburg.de> wrote:
> [..]
> there is a Bugzilla ticket that covers this issue:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=35828
>
> You might want to have a look. A patch to solve this problem would be
> highly appreciated.
> [..]
--
Cheers,
Jorge
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [configuration] Unexpected behavior
Posted by Oliver Heger <he...@med.uni-marburg.de>.
Jorge Ferrer schrieb:
> Hi,
>
> Just in case someone also applied the proposed woraround, I have found
> an important secondary effect when calling getProperties() which
> converts the configuration to a java.util.Properties instance: it uses
> the CHARACTER_NEVER_USED to serialize every multi-valued property.
>
> As a result, I'm trying to implement a patch to allow disabling
> DELIMITER parsing for certain configuration. I'm having difficulties
> as currently the DELIMITER is common for all configurations of the
> JVM. So I have to change that first to make it per configuration. If
> I'm able to make it work I'll send a patch.
>
<snip/>
Jorge,
there is a Bugzilla ticket that covers this issue:
http://issues.apache.org/bugzilla/show_bug.cgi?id=35828
You might want to have a look. A patch to solve this problem would be
highly appreciated.
Thanks!
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [configuration] Unexpected behavior
Posted by Jorge Ferrer <jo...@gmail.com>.
Hi,
Just in case someone also applied the proposed woraround, I have found
an important secondary effect when calling getProperties() which
converts the configuration to a java.util.Properties instance: it uses
the CHARACTER_NEVER_USED to serialize every multi-valued property.
As a result, I'm trying to implement a patch to allow disabling
DELIMITER parsing for certain configuration. I'm having difficulties
as currently the DELIMITER is common for all configurations of the
JVM. So I have to change that first to make it per configuration. If
I'm able to make it work I'll send a patch.
On 11/28/05, Jorge Ferrer <jo...@gmail.com> wrote:
> [..]
> I have a workaround to disable this feature so that escaping is not
> necessary. It consists on changing the delimiter character (a comma by
> default) to one that will never appear in your configuration values:
>
> AbstractConfiguration.setDelimiter(CHARACTER_NEVER_USED);
>>[..]
--
cheers,
Jorge
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [configuration] Unexpected behavior
Posted by Jorge Ferrer <jo...@gmail.com>.
Hi Borut,
I have a workaround to disable this feature so that escaping is not
necessary. It consists on changing the delimiter character (a comma by
default) to one that will never appear in your configuration values:
AbstractConfiguration.setDelimiter(CHARACTER_NEVER_USED);
Cheers,
Jorge
On 11/20/05, Borut Bolčina <bo...@najdi.si> wrote:
> Oliver Heger wrote:
>
> > Borut Bolčina wrote:
> >
> >> Hi,
> >>
> >> when having an attribute value with commas in XML configuration file,
> >> this value gets splitted. An example:
> >>
> >> <?xml version="1.0" encoding="UTF-8"?>
> >> <questionnaire>
> >> <set week="42" text="Questions for first week">
> >> <question text="First question, something after comma.">
> >> <=== offending
> >> <answers>
> >> <answer>(I) 1.a</answer>
> >> <answer correct="true">(I) 1.b</answer>
> >> <answer>(I) 1.c</answer>
> >> </answers>
> >> </question>
> >> <question text="Second question, which includes comma in the
> >> sentence."> <=== offending
> >> <answers>
> >> <answer correct="true">(I) 2.a</answer>
> >> <answer>(I) 2.b</answer>
> >> <answer>(I) 2.c</answer>
> >> </answers>
> >> </question>
> >> ...
> >>
> >> When calling this method
> >>
> >>
> >> /**
> >> * @return all questions from XML configuration file
> >> */
> >> @SuppressWarnings("unchecked")
> >> public Collection<String> getQuestions() {
> >> String ofQuestions = "set.question[@text]";
> >> return config.getList(ofQuestions);
> >> }
> >>
> >> the returned list contains *four* instead of two questions:
> >> 1.) First question
> >> 2.) something after comma
> >> 3.) Second question
> >> 4.) which includes comma in the sentence
> >>
> >> Is this by design? I think this should not work this way.
> >>
> >> Regards,
> >> Borut
> >>
> > The "," character is per default interpreted as property value
> > delimiter. That means if a comma is found in an attribute or in the
> > text value of an XML element, the text will be splitted and two values
> > will be stored. This mechanism is described in the section "Lists and
> > arrays" of the properties howto
> > (http://jakarta.apache.org/commons/configuration/howto_properties.html),
> > and XMLConfiguration adapted this behavior to be compatible.
> >
> > The easiest way to solve your problem is to escape the commas in your
> > attributes with a backslash, e.g.
> >
> > <question text="Second question\, which includes comma in the sentence.">
> >
> > Then the strings won't get splitted.
> >
> > Oliver
>
> Oliver thanks for quick reply. I tried as you suggested and it works. I
> was aware of the "Lists and arrays" feature and it makes sense for the
> flat world of ordinary property files. IMO this should not be the way in
> structured world.
>
> In the meantime I wrote XPath extraction methods (nothing general, just
> for my purposes) to mimic the behavior, but with greater flexibility.
>
> Keep up the good work, bye
> Borut
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>
--
Un abrazo,
Jorge
Re: [configuration] Unexpected behavior
Posted by Borut Bolčina <bo...@najdi.si>.
Oliver Heger wrote:
> Borut Bolčina wrote:
>
>> Hi,
>>
>> when having an attribute value with commas in XML configuration file,
>> this value gets splitted. An example:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <questionnaire>
>> <set week="42" text="Questions for first week">
>> <question text="First question, something after comma.">
>> <=== offending
>> <answers>
>> <answer>(I) 1.a</answer>
>> <answer correct="true">(I) 1.b</answer>
>> <answer>(I) 1.c</answer>
>> </answers>
>> </question>
>> <question text="Second question, which includes comma in the
>> sentence."> <=== offending
>> <answers>
>> <answer correct="true">(I) 2.a</answer>
>> <answer>(I) 2.b</answer>
>> <answer>(I) 2.c</answer>
>> </answers>
>> </question>
>> ...
>>
>> When calling this method
>>
>>
>> /**
>> * @return all questions from XML configuration file
>> */
>> @SuppressWarnings("unchecked")
>> public Collection<String> getQuestions() {
>> String ofQuestions = "set.question[@text]";
>> return config.getList(ofQuestions);
>> }
>>
>> the returned list contains *four* instead of two questions:
>> 1.) First question
>> 2.) something after comma
>> 3.) Second question
>> 4.) which includes comma in the sentence
>>
>> Is this by design? I think this should not work this way.
>>
>> Regards,
>> Borut
>>
> The "," character is per default interpreted as property value
> delimiter. That means if a comma is found in an attribute or in the
> text value of an XML element, the text will be splitted and two values
> will be stored. This mechanism is described in the section "Lists and
> arrays" of the properties howto
> (http://jakarta.apache.org/commons/configuration/howto_properties.html),
> and XMLConfiguration adapted this behavior to be compatible.
>
> The easiest way to solve your problem is to escape the commas in your
> attributes with a backslash, e.g.
>
> <question text="Second question\, which includes comma in the sentence.">
>
> Then the strings won't get splitted.
>
> Oliver
Oliver thanks for quick reply. I tried as you suggested and it works. I
was aware of the "Lists and arrays" feature and it makes sense for the
flat world of ordinary property files. IMO this should not be the way in
structured world.
In the meantime I wrote XPath extraction methods (nothing general, just
for my purposes) to mimic the behavior, but with greater flexibility.
Keep up the good work, bye
Borut
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [configuration] Unexpected behavior
Posted by Oliver Heger <ol...@t-online.de>.
Borut Bolčina wrote:
> Hi,
>
> when having an attribute value with commas in XML configuration file,
> this value gets splitted. An example:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <questionnaire>
> <set week="42" text="Questions for first week">
> <question text="First question, something after comma."> <===
> offending
> <answers>
> <answer>(I) 1.a</answer>
> <answer correct="true">(I) 1.b</answer>
> <answer>(I) 1.c</answer>
> </answers>
> </question>
> <question text="Second question, which includes comma in the
> sentence."> <=== offending
> <answers>
> <answer correct="true">(I) 2.a</answer>
> <answer>(I) 2.b</answer>
> <answer>(I) 2.c</answer>
> </answers>
> </question>
> ...
>
> When calling this method
>
>
> /**
> * @return all questions from XML configuration file
> */
> @SuppressWarnings("unchecked")
> public Collection<String> getQuestions() {
> String ofQuestions = "set.question[@text]";
> return config.getList(ofQuestions);
> }
>
> the returned list contains *four* instead of two questions:
> 1.) First question
> 2.) something after comma
> 3.) Second question
> 4.) which includes comma in the sentence
>
> Is this by design? I think this should not work this way.
>
> Regards,
> Borut
>
The "," character is per default interpreted as property value
delimiter. That means if a comma is found in an attribute or in the text
value of an XML element, the text will be splitted and two values will
be stored. This mechanism is described in the section "Lists and arrays"
of the properties howto
(http://jakarta.apache.org/commons/configuration/howto_properties.html),
and XMLConfiguration adapted this behavior to be compatible.
The easiest way to solve your problem is to escape the commas in your
attributes with a backslash, e.g.
<question text="Second question\, which includes comma in the sentence.">
Then the strings won't get splitted.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org