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
work.
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.host=localhost
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).
WDYT?
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
HierarchicalConfigurations.
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.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
