AbstractConfiguration provides a static setDelimiter() method, which
takes a char that will be interpreted as a list delimiter. So if this
character is detected in a string passed to the setProperty() or
addProperty() methods, the string will be splitted into multiple values.
To disable this behavior you can simply set the delimiter character to a
value that does not occur in your properties, e.g. '\0'. An alternative
is to quote occurences of the delimiter character with a back slash
(e.g. "Hello\, world"). They will then be ignored.
Does this help you with your problem?
Oliver
Moran Ben-David wrote:
I have dug deeper into the commons configuration codebase and uncovered the
exact place where the decision to do multi-valued substitution is made:
(in PropertyConverter.java)
public static Iterator toIterator(Object value, char delimiter)
{
...
if (value instanceof String)
{
String s = (String) value;
if (s.indexOf(delimiter) > 0)
{
return split((String) value, delimiter).iterator();
}
else
{
return new SingletonIterator(value);
}
}
...
}
I think the easiest thing for me to do is to
1. overload toIterator:
public static Iterator toIterator(Object value);
This function would just disregard the delimiter case of the above function
but essentially will do the same thing.
2. add a flag to the AbstractConfiguration class to tell wether to do
multivalued substituions.
3. put a condition in AbstractConfiguration.addProperty(String, Object) to
look at the flag cand call the appropriate version of
PropertyConverter.toIterator().
4. overload the constructor of AbstractConfiguration to accept
initialization of the substitution strategy flag.
5. construct my PropertiesConfiguration (in my custom code) with a
flag=false passed. I.e. don't substitute.
My appoligies if this is a bit of "thinking outloud". I understand that
this might violate some of the design principles in Commons Configuration.
I guess that's me saying that I appreciate any guidance anyone has to offer
in this change.
What will definitely not be fun, is that my code base will diverge from the
trunk of commons configuration. Perhaps I ought to think of subclassing
PropertiesConfiguration to handle this.. that might be smarter.. though
calls like super.addProperty might pose a problem.
Thanks for reading if you got this far,
Moran Ben-David
http://www.place-base.com
-----Original Message-----
From: Moran Ben-David [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 17, 2005 11:01 AM
To: 'Jakarta Commons Users List'
Subject: [configuration] Property Substitution Policy
Hi all,
I have a configuration which ends up having multiple valued properties as
such:
v1 = value1.1
v1 = value1.2
v2 = ${v1}
My problem is that v2 ends up being set with multi-valued v1.
v2 = [value1.1, value1.2]
Has anybody tried to change this policy to use only the first element in
the
substitution?
It seems to me that causing the PropertiesReader to toggle, based on some
sort of parameter passed into the PropertiesConfiguration. The reader
would
toggle between full substitution and first-value substitution.
A better design might be to pass in a strategy object that handles that?
I.e. allowing anyone declaring the PropertiesConfiguration to either
override the existing subbing strategy by passing in
SubstitutionStrategy/Substitutor object.
Does any one know if this ability is already in the commons configuration
code base? Is it in the works? I'm looking to at least benefit from
design
guidance form any commons developers if I do make this change myself.
Thanks,
Moran Ben-David
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
