commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [configuration] Local lookup fix & enhancement
Date Fri, 06 Mar 2009 21:26:11 GMT

On Mar 6, 2009, at 12:59 PM, Jörg Schaible wrote:

> Hi folks,
> it has been a while since I committed last time something to  
> configuration.
> It has been improved a lot since then and one of the newer features  
> are the
> user defined StrLookup support. However, nothing is perfect and I'd  
> like to
> work somewhat on it. My proposed
> 1/ While it is quite easy to register a global StrLookup, it is not  
> so easy
> to work with the local ones. Especially since those are no longer  
> available
> for a SubsetConfiguration:
> moduleA.value=${my:foo}
> assertEquals("bar", config.getString("moduleA.value"));
> assertEquals("bar", config.subset("moduleA").getString("value"));
> The second assert fails. I've prepared patches to support this  
> scenario.

This makes sense. But the same thing needs to work it if is a  
HierarchicalConfiguration. So if the caller does  
config.configurationAt("moduleA").getString("value") it needs to also  

Also, make sure any patches also get applied to the experimental  
branch. In general, the goal of the experimental branch is to only  
deal with hierarchical configurations and treat property files as just  
a simpler variation of that.

> 2/ In my use case I have a big "unified" configuration, actually  
> based on a
> CompositeConfiguration with an overloaded createInterpolator method.  
> The
> configuration itself combines system properties, an individual
> configuration for a module and a default configuration file. Each  
> module
> will use then its own subset (so it can be used or tested  
> individually),
> but the scenario allows me to override every configuration value from
> command line or use a default value in the standard file. However,
> sometimes the individual modules share some settings and therefore I
> invented auto-lookups based on a local StrLookup. These auto-lookup  
> are
> defined automatically using the keys in the configuration itself, i.e.
> auto.lookup.ldap.port=636
> auto.lookup.ldap.base=dc=apache,dc=org
> auto.lookup.wsdl.serviceA=http://localhost:4711/serviceA
> auto.lookup.wsdl.serviceB=http://localhost:4711/serviceB
> moduleA.serviceA=${wsdl:serviceA}
> moduleA.ldap.url=ldap://${ldap:host}:${ldap:port}/${ldap:base}
> moduleB.serviceB=${wsdl:serviceB}
> moduleB.ldap.url=ldap://${ldap:host}:${ldap:port}/${ldap:base}
> moduleC.serviceA=${wsdl:serviceA}
> moduleC.serviceB=${wsdl:serviceB}
> Explanation:
> - "auto.lookup" defines the root node for the automatically  
> registered local
> lookups (the name of this root can be set individually for a  
> configuration)
> - the next node defines the namespace of the lookup
> - all nodes below "auto.lookup.XXX" are part of the local lookup
> - even for subsets of the individual modules these local auto- 
> lookups work:
> config.subset("moduleA").getString("serviceA")
> As said I've implemented this currently in a derived class of
> CompositeConfiguration, but it might be added to  
> AbstractConfiguration. The
> name of the auto-lookup root is provided as ctor param. The local  
> StrLookup
> itself is again based on a Configuration (actually a subset of the  
> name
> giving node).
I tend not to use CompositeConfiguration - we only use  
HierarchicalConfigurations which CompositeConfiguration unfortunately  
doesn't support.

Basically it looks like you created a new Lookup class and a way to  
populate data the Lookup uses. I'm OK with that. However, the devil is  
in the details. How the Lookup gets populated from the Configuration  
would be worth a look-see. Again, this feature should also work for  

Just as an FYI - I have made some enhancements to allow Commons  
Configuration to leverage Commons VFS. I haven't committed them  
because they need the latest Commons VFS code and since those haven't  
been released the Commons Configuraton build would fail.  Commons VFS  
won't be required at runtime unless the user wants to take advantage  
of this.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message