commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Moran Ben-David" <mo...@place-base.com>
Subject RE: [configuration] Property Substitution Policy
Date Wed, 17 Aug 2005 15:23:04 GMT
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:moran@place-base.com]
> 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: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org


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


Mime
View raw message