[configuration] Property Substitution Policy

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[configuration] Property Substitution Policy

Moran Ben-David
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [configuration] Property Substitution Policy

Moran Ben-David
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:[hidden email]]
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Property Substitution Policy

Oliver Heger-2
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:[hidden email]]
>>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: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [configuration] Property Substitution Policy

Moran Ben-David
Thanks for the help, Oliver.

However, I think I may have led you astray with my proposed code change.  It
was a bit hasty of me and I was suggesting doing the opposite of what I
wanted to do.

I was actually trying to get the substitution to only use the 1st value in a
multi-valued property.  For example, a file like

        V1 = value1
        V1 = value2
        Myprop = {$V1}

Would result in a configuration having

        Myprop = value1

This way, when I do config.getString("Myprop") I'd get "value1" and not
"[value1, value2]".

From what I can tell you're suggestion is a different way of actually
causing

        Myprop = [value1, value2]

I think.  I'm not sure.. I will experiment with what you've suggested.
Thank you!

If it's not the case, I think what I should originally have suggested was to
write toIterator(Object value) to pull off the first value from the split
and pass an iterator on just that single value.  

Again.. thanks for bearing with my mistakes in explaining this.

Moran

> -----Original Message-----
> From: Oliver Heger [mailto:[hidden email]]
> Sent: Wednesday, August 17, 2005 2:21 PM
> To: Jakarta Commons Users List
> Subject: Re: [configuration] Property Substitution Policy
>
> 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:[hidden email]]
> >>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: [hidden email]
> >>For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [hidden email]
> >For additional commands, e-mail: [hidden email]
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [configuration] Property Substitution Policy

Moran Ben-David
I guess a different question whose answer could achieve the same result
is...

Can one turn off multi-value construction of properties?  

That is, can one cause multiple occurrences of a property not to accumulate
values into a string of commas... but instead just overwrite the property
value.. or not overwrite it at all?

For example, a file containing:

V1 = value1
V1 = value2

Would result in a configuration of

V1 = value1

Or

V1 = value2

And not

V1 = value1, value2

Thanks,
Moran

> -----Original Message-----
> From: Moran Ben-David [mailto:[hidden email]]
> Sent: Wednesday, August 17, 2005 2:57 PM
> To: 'Jakarta Commons Users List'
> Subject: RE: [configuration] Property Substitution Policy
>
> Thanks for the help, Oliver.
>
> However, I think I may have led you astray with my proposed code change.
> It
> was a bit hasty of me and I was suggesting doing the opposite of what I
> wanted to do.
>
> I was actually trying to get the substitution to only use the 1st value in
> a
> multi-valued property.  For example, a file like
>
> V1 = value1
> V1 = value2
> Myprop = {$V1}
>
> Would result in a configuration having
>
> Myprop = value1
>
> This way, when I do config.getString("Myprop") I'd get "value1" and not
> "[value1, value2]".
>
> From what I can tell you're suggestion is a different way of actually
> causing
>
> Myprop = [value1, value2]
>
> I think.  I'm not sure.. I will experiment with what you've suggested.
> Thank you!
>
> If it's not the case, I think what I should originally have suggested was
> to
> write toIterator(Object value) to pull off the first value from the split
> and pass an iterator on just that single value.
>
> Again.. thanks for bearing with my mistakes in explaining this.
>
> Moran
>
> > -----Original Message-----
> > From: Oliver Heger [mailto:[hidden email]]
> > Sent: Wednesday, August 17, 2005 2:21 PM
> > To: Jakarta Commons Users List
> > Subject: Re: [configuration] Property Substitution Policy
> >
> > 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:[hidden email]]
> > >>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: [hidden email]
> > >>For additional commands, e-mail: [hidden email]
> > >>
> > >>
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: [hidden email]
> > >For additional commands, e-mail: [hidden email]
> > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Property Substitution Policy

Oliver Heger
Sorry if I did not understand your problem correctly.

Neither of the Configuration implementations so far support suppression
of multiple property values. (Background is the assumption that if a
user defines these values in a configuration file, he/she will probably
later want to access them.)

But if you only want the first value, can't you simply use one of the
simple getter methods like getString(), getInt() etc.? These methods can
be used on properties with multiple values, too. They then return only
the first value. This also works with interpolation.

Or you can use the getList() method and then access single elements of
the returned list by index.

Maybe I still don't understand your use case fully.

Oliver

Moran Ben-David schrieb:

> I guess a different question whose answer could achieve the same result
> is...
>
> Can one turn off multi-value construction of properties?  
>
> That is, can one cause multiple occurrences of a property not to accumulate
> values into a string of commas... but instead just overwrite the property
> value.. or not overwrite it at all?
>
> For example, a file containing:
>
> V1 = value1
> V1 = value2
>
> Would result in a configuration of
>
> V1 = value1
>
> Or
>
> V1 = value2
>
> And not
>
> V1 = value1, value2
>
> Thanks,
> Moran
>
>
>>-----Original Message-----
>>From: Moran Ben-David [mailto:[hidden email]]
>>Sent: Wednesday, August 17, 2005 2:57 PM
>>To: 'Jakarta Commons Users List'
>>Subject: RE: [configuration] Property Substitution Policy
>>
>>Thanks for the help, Oliver.
>>
>>However, I think I may have led you astray with my proposed code change.
>>It
>>was a bit hasty of me and I was suggesting doing the opposite of what I
>>wanted to do.
>>
>>I was actually trying to get the substitution to only use the 1st value in
>>a
>>multi-valued property.  For example, a file like
>>
>> V1 = value1
>> V1 = value2
>> Myprop = {$V1}
>>
>>Would result in a configuration having
>>
>> Myprop = value1
>>
>>This way, when I do config.getString("Myprop") I'd get "value1" and not
>>"[value1, value2]".
>>
>>From what I can tell you're suggestion is a different way of actually
>>causing
>>
>> Myprop = [value1, value2]
>>
>>I think.  I'm not sure.. I will experiment with what you've suggested.
>>Thank you!
>>
>>If it's not the case, I think what I should originally have suggested was
>>to
>>write toIterator(Object value) to pull off the first value from the split
>>and pass an iterator on just that single value.
>>
>>Again.. thanks for bearing with my mistakes in explaining this.
>>
>>Moran
>>
>>
>>>-----Original Message-----
>>>From: Oliver Heger [mailto:[hidden email]]
>>>Sent: Wednesday, August 17, 2005 2:21 PM
>>>To: Jakarta Commons Users List
>>>Subject: Re: [configuration] Property Substitution Policy
>>>
>>>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:[hidden email]]
>>>>>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: [hidden email]
>>>>>For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: [hidden email]
>>>>For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [configuration] Property Substitution Policy

Moran Ben-David
> Sorry if I did not understand your problem correctly.

Thanks for the reply again, Oliver.  Your patience is much appreciated.
 
> Neither of the Configuration implementations so far support suppression
> of multiple property values. (Background is the assumption that if a
> user defines these values in a configuration file, he/she will probably
> later want to access them.)

My reasoning for wanting to disregard the additional values for properties
is that in my project, we are using a set of files to allow developers to
Override property values.  This allows us to check-in properties files into
our Source/Version Control system and override with a custom file that isn't
checked in.  E.g.  our single properties file is default.config:

include = gcm.extension.config
include = log4j.config
include = gcm.config

Both log4j.config and gcm.config are checked in to source control.  And we
look to them to provide default values (and comments) for each configuration
property.

However, gcm.extension.config is not checked in.  That allows developers or
installations on various machines to alert the configuration just for that
install.

The fact that gcm.extension.config is not checked in allows us to commit our
configuration directory changes without worrying about overriding anyone
else's configuration.

This approach allows us to share a configuration by checking in and
overriding without the risk of affecting others.

> But if you only want the first value, can't you simply use one of the
> simple getter methods like getString(), getInt() etc.? These methods can
> be used on properties with multiple values, too. They then return only
> the first value. This also works with interpolation.

Yes I tried that when I explicitly ask for a configuration value.  However,
when the AbstractFileConfiguration (I think it's that class) performs the
substitution, it uses the entire multi-value of the property.  That
algorithm from what I can tell is not under my control, unless I change the
commons-configuration source code of course.

> Maybe I still don't understand your use case fully.

I hope I've done a better job describing it this time.  Thanks again!

Moran


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Property Substitution Policy

Oliver Heger-2
Moran Ben-David wrote:

>>Sorry if I did not understand your problem correctly.
>>    
>>
>
>Thanks for the reply again, Oliver.  Your patience is much appreciated.
>
>  
>
>>Neither of the Configuration implementations so far support suppression
>>of multiple property values. (Background is the assumption that if a
>>user defines these values in a configuration file, he/she will probably
>>later want to access them.)
>>    
>>
>
>My reasoning for wanting to disregard the additional values for properties
>is that in my project, we are using a set of files to allow developers to
>Override property values.  This allows us to check-in properties files into
>our Source/Version Control system and override with a custom file that isn't
>checked in.  E.g.  our single properties file is default.config:
>
>include = gcm.extension.config
>include = log4j.config
>include = gcm.config
>
>Both log4j.config and gcm.config are checked in to source control.  And we
>look to them to provide default values (and comments) for each configuration
>property.
>
>However, gcm.extension.config is not checked in.  That allows developers or
>installations on various machines to alert the configuration just for that
>install.
>
>The fact that gcm.extension.config is not checked in allows us to commit our
>configuration directory changes without worrying about overriding anyone
>else's configuration.
>
>This approach allows us to share a configuration by checking in and
>overriding without the risk of affecting others.
>
>  
>
>>But if you only want the first value, can't you simply use one of the
>>simple getter methods like getString(), getInt() etc.? These methods can
>>be used on properties with multiple values, too. They then return only
>>the first value. This also works with interpolation.
>>    
>>
>
>Yes I tried that when I explicitly ask for a configuration value.  However,
>when the AbstractFileConfiguration (I think it's that class) performs the
>substitution, it uses the entire multi-value of the property.  That
>algorithm from what I can tell is not under my control, unless I change the
>commons-configuration source code of course.
>
>  
>
>>Maybe I still don't understand your use case fully.
>>    
>>
>
>I hope I've done a better job describing it this time.  Thanks again!
>
>Moran
>
>
>  
>
Yes, I think, I now understand your use case better.

Configuration's typical solution for this use case is setting up a
ConfigurationFactory. This factory is given an XML configuration
definition file, which lists the configuration sources to include. From
these sources a CompositeConfiguration can be created, which should
exactly have the desired behavior: Properties in the first included
configuration source overwrite properties with the same keys in later
included configuration sources.

So instead of using the include machanism of PropertiesConfiguration you
can use a ConfigurationFactory to manage your combined properties. More
information about this topic and some usage examples can be found in the
howtos:
http://jakarta.apache.org/commons/configuration/howto_configurationfactory.html

I did not test this, but I think, this approach will also work with
interpolation because CompositeConfiguration by inheriting from
AbstractConfiguration is able to correctly resolve the interpolated keys.

I hope this helps you solve your problem.
Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Property Substitution Policy

Emmanuel Bourg-3
In reply to this post by Moran Ben-David
Hi Moran,

Moran Ben-David wrote:

> I was actually trying to get the substitution to only use the 1st value in a
> multi-valued property.  For example, a file like
>
> V1 = value1
> V1 = value2
> Myprop = ${V1}
>
> Would result in a configuration having
>
> Myprop = value1
>
> This way, when I do config.getString("Myprop") I'd get "value1" and not
> "[value1, value2]".

I tend to agree on this, the interpolated value should be a scalar, this
would be consistent with the getString() method called on a multi-valued
property.

However regarding your use case I agree with Oliver, using a
CompositeConfiguration is the right solution. You can build it
programatically, or use the ConfigurationFactory with a configuration
descriptor.

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [configuration] Property Substitution Policy

Moran Ben-David
Hi guys,

Thanks again for inspecting this problem with me and hashing out my various
options.  I have taken the liberty of making some modifications to 2 classes
in Commons Configuration (attached) in order to get it to do what I wanted.

Is it possible to contribute this to Commons Configuration?  I've tried to
do a good job in this code change by providing the test case.  I plan to use
commons configuration for as long as I can think and would hate to have to
make this change for every new version I get.

The summary of these changes is that I added a Boolean flag to tell the
interpolation algorithm whether to substitute using the entire multi-valued
property or just the first value.  I.e., an if statement determining whether
getString or getPoroperty are used.  I added a test case for this in what I
think is the appropriate place.

My exact changes are as follows:

TestBaseConfiguration.java(592): test case for making sure flag switches
behaviour properly.

        public void testMultiValuedPropertyInterpolation() throws Exception
        {
                config.setProperty("multi", "value1");
                config.addProperty("multi", "value2");
                config.setProperty("interpolated", "${multi}");
               
                config.setInterpolateAllValues(false);
                String expectedValue = "value1";
                assertEquals(config.getString("interpolated"),
expectedValue);
               
                config.setInterpolateAllValues(true);
                expectedValue = "" + config.getProperty("multi");
               
                assertEquals(config.getString("interpolated"),
expectedValue);
        }

Abstractconfiguration.java(59): added flag

        /**
         * Determines whether all values of a property are used or just
         *the first when
         * substituting tokens.
         */
        private boolean interpolateAllValues = true;

Abstractconfiguration.java(209): the if statement in interpolateHelper() to
use getString or getProperty:

        Object value;
        if (isInterpolateAllValues())
        {
                value = getProperty(variable);
        }
        else
        {
                value = getString(variable);
        }

Abstractconfiguration.java(977): setter and getter for flag:

        public void setInterpolateAllValues(boolean b)
        {
                this.interpolateAllValues = b;
        }

        public boolean isInterpolateAllValues()
        {
                return interpolateAllValues;
        }

> -----Original Message-----
> From: Emmanuel Bourg [mailto:[hidden email]]
> Sent: Tuesday, August 23, 2005 8:49 AM
> To: Jakarta Commons Users List
> Subject: Re: [configuration] Property Substitution Policy
>
> Hi Moran,
>
> Moran Ben-David wrote:
>
> > I was actually trying to get the substitution to only use the 1st value
> in a
> > multi-valued property.  For example, a file like
> >
> > V1 = value1
> > V1 = value2
> > Myprop = ${V1}
> >
> > Would result in a configuration having
> >
> > Myprop = value1
> >
> > This way, when I do config.getString("Myprop") I'd get "value1" and not
> > "[value1, value2]".
>
> I tend to agree on this, the interpolated value should be a scalar, this
> would be consistent with the getString() method called on a multi-valued
> property.
>
> However regarding your use case I agree with Oliver, using a
> CompositeConfiguration is the right solution. You can build it
> programatically, or use the ConfigurationFactory with a configuration
> descriptor.
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

AbstractConfiguration.java (26K) Download Attachment
TestBaseConfiguration.java (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Property Substitution Policy

Oliver Heger-2
Moran Ben-David wrote:

>Hi guys,
>
>Thanks again for inspecting this problem with me and hashing out my various
>options.  I have taken the liberty of making some modifications to 2 classes
>in Commons Configuration (attached) in order to get it to do what I wanted.
>
>Is it possible to contribute this to Commons Configuration?  I've tried to
>do a good job in this code change by providing the test case.  I plan to use
>commons configuration for as long as I can think and would hate to have to
>make this change for every new version I get.
>
>The summary of these changes is that I added a Boolean flag to tell the
>interpolation algorithm whether to substitute using the entire multi-valued
>property or just the first value.  I.e., an if statement determining whether
>getString or getPoroperty are used.  I added a test case for this in what I
>think is the appropriate place.
>  
>
Hm, I am wondering if we need the flag and the handling of multi valued
properties at all.

The interpolate() method is called at two different places: in
getString() for interpolating the return value and in getStringArray()
for processing the single array elements. This context IMO makes it
quite clear that its result should always be a single value and not a
somehow to a string converted list of values. This will then be
consistent with how getString() itself deals with multi-valued properties.

IIRC your original question was how to turn off those multiple return
values. So I suppose you do not have a concrete use case for this
behavior either, do you?

So I would suggest to fix interpolate() to always return the first value
if there are multiple.

Oliver

<snip>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Property Substitution Policy

Eric Pugh-2
Does this suggest that we need to be able to hand in a  
"InterpolationStrategy" object to Commons Config?  Maybe start out  
with a default that is based around the existing logic, and then  
allow other people to provide there own?  Versus adding more booleans  
and flags to the existing logic?

Eric

On Aug 26, 2005, at 10:02 AM, Oliver Heger wrote:


> Moran Ben-David wrote:
>
>
>
>> Hi guys,
>>
>> Thanks again for inspecting this problem with me and hashing out  
>> my various
>> options.  I have taken the liberty of making some modifications to  
>> 2 classes
>> in Commons Configuration (attached) in order to get it to do what  
>> I wanted.
>>
>> Is it possible to contribute this to Commons Configuration?  I've  
>> tried to
>> do a good job in this code change by providing the test case.  I  
>> plan to use
>> commons configuration for as long as I can think and would hate to  
>> have to
>> make this change for every new version I get.
>>
>> The summary of these changes is that I added a Boolean flag to  
>> tell the
>> interpolation algorithm whether to substitute using the entire  
>> multi-valued
>> property or just the first value.  I.e., an if statement  
>> determining whether
>> getString or getPoroperty are used.  I added a test case for this  
>> in what I
>> think is the appropriate place.
>>
>>
>>
> Hm, I am wondering if we need the flag and the handling of multi  
> valued properties at all.
>
> The interpolate() method is called at two different places: in  
> getString() for interpolating the return value and in getStringArray
> () for processing the single array elements. This context IMO makes  
> it quite clear that its result should always be a single value and  
> not a somehow to a string converted list of values. This will then  
> be consistent with how getString() itself deals with multi-valued  
> properties.
>
> IIRC your original question was how to turn off those multiple  
> return values. So I suppose you do not have a concrete use case for  
> this behavior either, do you?
>
> So I would suggest to fix interpolate() to always return the first  
> value if there are multiple.
>
> Oliver
>
> <snip>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [configuration] Property Substitution Policy

Moran Ben-David
I gather from Oliver's analysis that the existing behaviour for
interpolating multi-values isn't useful in any case.  So I think that means
it's going to be changed to only use the first value from a multi-list as
the substitute.

moran

> -----Original Message-----
> From: Eric Pugh [mailto:[hidden email]]
> Sent: Monday, August 29, 2005 10:05 PM
> To: Jakarta Commons Users List
> Subject: Re: [configuration] Property Substitution Policy
>
> Does this suggest that we need to be able to hand in a
> "InterpolationStrategy" object to Commons Config?  Maybe start out
> with a default that is based around the existing logic, and then
> allow other people to provide there own?  Versus adding more booleans
> and flags to the existing logic?
>
> Eric
>
> On Aug 26, 2005, at 10:02 AM, Oliver Heger wrote:
>
>
> > Moran Ben-David wrote:
> >
> >
> >
> >> Hi guys,
> >>
> >> Thanks again for inspecting this problem with me and hashing out
> >> my various
> >> options.  I have taken the liberty of making some modifications to
> >> 2 classes
> >> in Commons Configuration (attached) in order to get it to do what
> >> I wanted.
> >>
> >> Is it possible to contribute this to Commons Configuration?  I've
> >> tried to
> >> do a good job in this code change by providing the test case.  I
> >> plan to use
> >> commons configuration for as long as I can think and would hate to
> >> have to
> >> make this change for every new version I get.
> >>
> >> The summary of these changes is that I added a Boolean flag to
> >> tell the
> >> interpolation algorithm whether to substitute using the entire
> >> multi-valued
> >> property or just the first value.  I.e., an if statement
> >> determining whether
> >> getString or getPoroperty are used.  I added a test case for this
> >> in what I
> >> think is the appropriate place.
> >>
> >>
> >>
> > Hm, I am wondering if we need the flag and the handling of multi
> > valued properties at all.
> >
> > The interpolate() method is called at two different places: in
> > getString() for interpolating the return value and in getStringArray
> > () for processing the single array elements. This context IMO makes
> > it quite clear that its result should always be a single value and
> > not a somehow to a string converted list of values. This will then
> > be consistent with how getString() itself deals with multi-valued
> > properties.
> >
> > IIRC your original question was how to turn off those multiple
> > return values. So I suppose you do not have a concrete use case for
> > this behavior either, do you?
> >
> > So I would suggest to fix interpolate() to always return the first
> > value if there are multiple.
> >
> > Oliver
> >
> > <snip>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Property Substitution Policy

Emmanuel Bourg-3
In reply to this post by Oliver Heger-2
Oliver Heger wrote:

> So I would suggest to fix interpolate() to always return the first value
> if there are multiple.

+1

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Property Substitution Policy

Oliver Heger-2
In reply to this post by Moran Ben-David
Exactly. I opened a Bugzilla ticket for this issue (#36447) and fixed it.

Oliver

Moran Ben-David wrote:

>I gather from Oliver's analysis that the existing behaviour for
>interpolating multi-values isn't useful in any case.  So I think that means
>it's going to be changed to only use the first value from a multi-list as
>the substitute.
>
>moran
>
>  
>
>>-----Original Message-----
>>From: Eric Pugh [mailto:[hidden email]]
>>Sent: Monday, August 29, 2005 10:05 PM
>>To: Jakarta Commons Users List
>>Subject: Re: [configuration] Property Substitution Policy
>>
>>Does this suggest that we need to be able to hand in a
>>"InterpolationStrategy" object to Commons Config?  Maybe start out
>>with a default that is based around the existing logic, and then
>>allow other people to provide there own?  Versus adding more booleans
>>and flags to the existing logic?
>>
>>Eric
>>
>>On Aug 26, 2005, at 10:02 AM, Oliver Heger wrote:
>>
>>
>>    
>>
>>>Moran Ben-David wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>Hi guys,
>>>>
>>>>Thanks again for inspecting this problem with me and hashing out
>>>>my various
>>>>options.  I have taken the liberty of making some modifications to
>>>>2 classes
>>>>in Commons Configuration (attached) in order to get it to do what
>>>>I wanted.
>>>>
>>>>Is it possible to contribute this to Commons Configuration?  I've
>>>>tried to
>>>>do a good job in this code change by providing the test case.  I
>>>>plan to use
>>>>commons configuration for as long as I can think and would hate to
>>>>have to
>>>>make this change for every new version I get.
>>>>
>>>>The summary of these changes is that I added a Boolean flag to
>>>>tell the
>>>>interpolation algorithm whether to substitute using the entire
>>>>multi-valued
>>>>property or just the first value.  I.e., an if statement
>>>>determining whether
>>>>getString or getPoroperty are used.  I added a test case for this
>>>>in what I
>>>>think is the appropriate place.
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>Hm, I am wondering if we need the flag and the handling of multi
>>>valued properties at all.
>>>
>>>The interpolate() method is called at two different places: in
>>>getString() for interpolating the return value and in getStringArray
>>>() for processing the single array elements. This context IMO makes
>>>it quite clear that its result should always be a single value and
>>>not a somehow to a string converted list of values. This will then
>>>be consistent with how getString() itself deals with multi-valued
>>>properties.
>>>
>>>IIRC your original question was how to turn off those multiple
>>>return values. So I suppose you do not have a concrete use case for
>>>this behavior either, do you?
>>>
>>>So I would suggest to fix interpolate() to always return the first
>>>value if there are multiple.
>>>
>>>Oliver
>>>
>>><snip>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>>      
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Property Substitution Policy

Jacob Kjome
Quoting Oliver Heger <[hidden email]>:

> Exactly. I opened a Bugzilla ticket for this issue (#36447) and fixed it.
>

Just to clarify, do you mean that if I have the following config...

<props>
    <url>http://www.boo.com/</url>
    <url>http://www.hoo.com/</url>
    <url>http://www.foo.com/</url>
</props>

And I did...

config.getProperty("url");

I would get only the first value, which is "http://www.boo.com/"?

I would hope that it would be an option to get a list of these URL's, delimited
by comma or whatever else is desired by the user.  In Ant's <xmlproperty> this
is very useful, especially if I want to loop over the list of URL's using
<antcontrib:for>, for instance.

I hope this discussion is about something else, because saying that having
multiple values in a delimited list is useless is short sighted.

Jake

> Oliver
>
> Moran Ben-David wrote:
>
> >I gather from Oliver's analysis that the existing behaviour for
> >interpolating multi-values isn't useful in any case.  So I think that means
> >it's going to be changed to only use the first value from a multi-list as
> >the substitute.
> >
> >moran
> >
> >
> >
> >>-----Original Message-----
> >>From: Eric Pugh [mailto:[hidden email]]
> >>Sent: Monday, August 29, 2005 10:05 PM
> >>To: Jakarta Commons Users List
> >>Subject: Re: [configuration] Property Substitution Policy
> >>
> >>Does this suggest that we need to be able to hand in a
> >>"InterpolationStrategy" object to Commons Config?  Maybe start out
> >>with a default that is based around the existing logic, and then
> >>allow other people to provide there own?  Versus adding more booleans
> >>and flags to the existing logic?
> >>
> >>Eric
> >>
> >>On Aug 26, 2005, at 10:02 AM, Oliver Heger wrote:
> >>
> >>
> >>
> >>
> >>>Moran Ben-David wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>Hi guys,
> >>>>
> >>>>Thanks again for inspecting this problem with me and hashing out
> >>>>my various
> >>>>options.  I have taken the liberty of making some modifications to
> >>>>2 classes
> >>>>in Commons Configuration (attached) in order to get it to do what
> >>>>I wanted.
> >>>>
> >>>>Is it possible to contribute this to Commons Configuration?  I've
> >>>>tried to
> >>>>do a good job in this code change by providing the test case.  I
> >>>>plan to use
> >>>>commons configuration for as long as I can think and would hate to
> >>>>have to
> >>>>make this change for every new version I get.
> >>>>
> >>>>The summary of these changes is that I added a Boolean flag to
> >>>>tell the
> >>>>interpolation algorithm whether to substitute using the entire
> >>>>multi-valued
> >>>>property or just the first value.  I.e., an if statement
> >>>>determining whether
> >>>>getString or getPoroperty are used.  I added a test case for this
> >>>>in what I
> >>>>think is the appropriate place.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Hm, I am wondering if we need the flag and the handling of multi
> >>>valued properties at all.
> >>>
> >>>The interpolate() method is called at two different places: in
> >>>getString() for interpolating the return value and in getStringArray
> >>>() for processing the single array elements. This context IMO makes
> >>>it quite clear that its result should always be a single value and
> >>>not a somehow to a string converted list of values. This will then
> >>>be consistent with how getString() itself deals with multi-valued
> >>>properties.
> >>>
> >>>IIRC your original question was how to turn off those multiple
> >>>return values. So I suppose you do not have a concrete use case for
> >>>this behavior either, do you?
> >>>
> >>>So I would suggest to fix interpolate() to always return the first
> >>>value if there are multiple.
> >>>
> >>>Oliver
> >>>
> >>><snip>
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: [hidden email]
> >>>For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [hidden email]
> >>For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [hidden email]
> >For additional commands, e-mail: [hidden email]
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [configuration] Property Substitution Policy

Moran Ben-David
> > Exactly. I opened a Bugzilla ticket for this issue (#36447) and fixed
> it.
> >
>
> Just to clarify, do you mean that if I have the following config...
>
> <props>
>     <url>http://www.boo.com/</url>
>     <url>http://www.hoo.com/</url>
>     <url>http://www.foo.com/</url>
> </props>
>
> And I did...
>
> config.getProperty("url");
>
> I would get only the first value, which is "http://www.boo.com/"?

No.  The case that we were talking about is when the property is used during
interpolation (substitution).  For example, if you had an extra property

     <url>http://www.boo.com/</url>
     <url>http://www.hoo.com/</url>
     <url>http://www.foo.com/</url>
     <myresource>${url}myresource.html</myresource>

The issue here is, should the entire list ("http://www.boo.com/,
http://www.hoo.com/, ...") be used to substitute into "myresource"?

I take it that Oliver's fix will be to have Config.getProperty("myresource")
return

        http://www.boo.com/myresource.html

But you'll have to check bugzilla as to what the fix will look like.




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [configuration] Property Substitution Policy

Jacob Kjome
Quoting Moran Ben-David <[hidden email]>:

> > > Exactly. I opened a Bugzilla ticket for this issue (#36447) and fixed
> > it.
> > >
> >
> > Just to clarify, do you mean that if I have the following config...
> >
> > <props>
> >     <url>http://www.boo.com/</url>
> >     <url>http://www.hoo.com/</url>
> >     <url>http://www.foo.com/</url>
> > </props>
> >
> > And I did...
> >
> > config.getProperty("url");
> >
> > I would get only the first value, which is "http://www.boo.com/"?
>
> No.  The case that we were talking about is when the property is used during
> interpolation (substitution).  For example, if you had an extra property
>
>      <url>http://www.boo.com/</url>
>      <url>http://www.hoo.com/</url>
>      <url>http://www.foo.com/</url>
>      <myresource>${url}myresource.html</myresource>
>
> The issue here is, should the entire list ("http://www.boo.com/,
> http://www.hoo.com/, ...") be used to substitute into "myresource"?
>
> I take it that Oliver's fix will be to have Config.getProperty("myresource")
> return
>
> http://www.boo.com/myresource.html
>

Oh, ok.  That does make more sense.  However, it doesn't make complete sense.
Seems like that's an error on the part of the config file writer being
ambiguous about what he/she is actually referring to.  Changing this behavior
to produce a more sensible looking value doesn't really help.  In fact, it
might mask the fact that the config file is written in an ambiguous way because
the value returned from Config.getProperty("myresource") doesn't look like
there's anything wrong with it because it is using a default URL (the first
one) even though that may not be the URL originally intended to be referenced.

For instance, think about the case where there is a config file with the 3 URL's
above.  Now a developer who doesn't know that order is meaningful, adds another
URL to the top rather than the bottom.  Now this new URL is returned by
Config.getProperty("myresource") when really the 2nd one was meant to be
returned.

Then again, if the config file developer referenced it like this (not sure if
syntax is right here, but you get the idea)...

<myresource>${url(1)}myresource.html</myresource>

..order would still be important.  But in this case, it is declared to be
important by the config file writer so future editors of the config file will
be tippped off that order is important and re-order accordingly.

I guess it is hard to say what's correct behavior.  In any case, I'm glad my
original assumption of what this discussion was all about was incorrect.


Jake

> But you'll have to check bugzilla as to what the fix will look like.
>




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [configuration] Property Substitution Policy

Moran Ben-David
I see what you're saying.  My original request to Oliver was to be able to
alter the behaviour of Configuration and interpolation from the outside.
That is, from my application's code.  I made some code changes to preserve
both old (using all the multi-list) and new (using the first value)
behaviours.

I am not sure what Oliver's take of your case is, but I believe he asked the
list if there were any cases that anyone had for keeping the existing
behaviour.  I guess your email is to that.

The great issue at I think is that some of us use multiple instances of the
variables assignments in config files to OVERRIDE (myself) while other use
them to ADD (yourself).

I don't think it's a badly written configuration when you have something
like a base file (with defaults) that also has an include at the top (for
the personal properties file.  What we do (in my team) is we check in the
base file, and don't check in the personal file.  In so doing, we can
publish configuration variables automatically to other's sandboxes by our
source repository system (svn).  However, we don't destroy our personal
settings since we don't check in the 'personal properties' file.

Wrote this email rather quickly, so I hope I've added to the discussion.

Thanks,
Moran

> -----Original Message-----
> From: Jacob Kjome [mailto:[hidden email]]
> Sent: Wednesday, August 31, 2005 5:37 PM
> To: Jakarta Commons Users List
> Subject: RE: [configuration] Property Substitution Policy
>
> Quoting Moran Ben-David <[hidden email]>:
>
> > > > Exactly. I opened a Bugzilla ticket for this issue (#36447) and
> fixed
> > > it.
> > > >
> > >
> > > Just to clarify, do you mean that if I have the following config...
> > >
> > > <props>
> > >     <url>http://www.boo.com/</url>
> > >     <url>http://www.hoo.com/</url>
> > >     <url>http://www.foo.com/</url>
> > > </props>
> > >
> > > And I did...
> > >
> > > config.getProperty("url");
> > >
> > > I would get only the first value, which is "http://www.boo.com/"?
> >
> > No.  The case that we were talking about is when the property is used
> during
> > interpolation (substitution).  For example, if you had an extra property
> >
> >      <url>http://www.boo.com/</url>
> >      <url>http://www.hoo.com/</url>
> >      <url>http://www.foo.com/</url>
> >      <myresource>${url}myresource.html</myresource>
> >
> > The issue here is, should the entire list ("http://www.boo.com/,
> > http://www.hoo.com/, ...") be used to substitute into "myresource"?
> >
> > I take it that Oliver's fix will be to have
> Config.getProperty("myresource")
> > return
> >
> > http://www.boo.com/myresource.html
> >
>
> Oh, ok.  That does make more sense.  However, it doesn't make complete
> sense.
> Seems like that's an error on the part of the config file writer being
> ambiguous about what he/she is actually referring to.  Changing this
> behavior
> to produce a more sensible looking value doesn't really help.  In fact, it
> might mask the fact that the config file is written in an ambiguous way
> because
> the value returned from Config.getProperty("myresource") doesn't look like
> there's anything wrong with it because it is using a default URL (the
> first
> one) even though that may not be the URL originally intended to be
> referenced.
>
> For instance, think about the case where there is a config file with the 3
> URL's
> above.  Now a developer who doesn't know that order is meaningful, adds
> another
> URL to the top rather than the bottom.  Now this new URL is returned by
> Config.getProperty("myresource") when really the 2nd one was meant to be
> returned.
>
> Then again, if the config file developer referenced it like this (not sure
> if
> syntax is right here, but you get the idea)...
>
> <myresource>${url(1)}myresource.html</myresource>
>
> ..order would still be important.  But in this case, it is declared to be
> important by the config file writer so future editors of the config file
> will
> be tippped off that order is important and re-order accordingly.
>
> I guess it is hard to say what's correct behavior.  In any case, I'm glad
> my
> original assumption of what this discussion was all about was incorrect.
>
>
> Jake
>
> > But you'll have to check bugzilla as to what the fix will look like.
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] Property Substitution Policy

Oliver Heger
In reply to this post by Jacob Kjome
Jacob Kjome schrieb:

> Quoting Moran Ben-David <[hidden email]>:
>
>
>>>>Exactly. I opened a Bugzilla ticket for this issue (#36447) and fixed
>>>
>>>it.
>>>
>>>Just to clarify, do you mean that if I have the following config...
>>>
>>><props>
>>>    <url>http://www.boo.com/</url>
>>>    <url>http://www.hoo.com/</url>
>>>    <url>http://www.foo.com/</url>
>>></props>
>>>
>>>And I did...
>>>
>>>config.getProperty("url");
>>>
>>>I would get only the first value, which is "http://www.boo.com/"?
>>
>>No.  The case that we were talking about is when the property is used during
>>interpolation (substitution).  For example, if you had an extra property
>>
>>     <url>http://www.boo.com/</url>
>>     <url>http://www.hoo.com/</url>
>>     <url>http://www.foo.com/</url>
>>     <myresource>${url}myresource.html</myresource>
>>
>>The issue here is, should the entire list ("http://www.boo.com/,
>>http://www.hoo.com/, ...") be used to substitute into "myresource"?
>>
>>I take it that Oliver's fix will be to have Config.getProperty("myresource")
>>return
>>
>> http://www.boo.com/myresource.html
>>
>
>
> Oh, ok.  That does make more sense.  However, it doesn't make complete sense.
> Seems like that's an error on the part of the config file writer being
> ambiguous about what he/she is actually referring to.  Changing this behavior
> to produce a more sensible looking value doesn't really help.  In fact, it
> might mask the fact that the config file is written in an ambiguous way because
> the value returned from Config.getProperty("myresource") doesn't look like
> there's anything wrong with it because it is using a default URL (the first
> one) even though that may not be the URL originally intended to be referenced.
>
> For instance, think about the case where there is a config file with the 3 URL's
> above.  Now a developer who doesn't know that order is meaningful, adds another
> URL to the top rather than the bottom.  Now this new URL is returned by
> Config.getProperty("myresource") when really the 2nd one was meant to be
> returned.
>
> Then again, if the config file developer referenced it like this (not sure if
> syntax is right here, but you get the idea)...
>
> <myresource>${url(1)}myresource.html</myresource>
>
> ..order would still be important.  But in this case, it is declared to be
> important by the config file writer so future editors of the config file will
> be tippped off that order is important and re-order accordingly.
>
> I guess it is hard to say what's correct behavior.  In any case, I'm glad my
> original assumption of what this discussion was all about was incorrect.
>
>
> Jake

ATM interpolation takes place only in getString() and for the single
elements of an array returned by getStringArray(). In this context using
only the first value of a multi-valued property IMO makes more sense
than working with a String representation of a value list, which cannot
be influenced (because simply toString() is called on this list).

But I agree with you that the "correct behavior" certainly depends on
personal view or a concrete use case. I made this fix to be included in
the 1.2 release to be consistent with the behavior of other getter
methods. For the future there is an enhancement request in Bugzilla to
improve interpolation features
(http://issues.apache.org/bugzilla/show_bug.cgi?id=35116). This will
also support custom interpolation strategies and will make it possible
to change the way multi-valued properties are treated.

Oliver

>
>
>>But you'll have to check bugzilla as to what the fix will look like.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12