Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of jak-commons-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
Mail-Followup-To: dev@commons.apache.org
To: dev@commons.apache.org
From: =?ISO-8859-1?Q?J=F6rg?= Schaible <joerg.schaible@gmx.de>
Subject: [configuration] Local lookup fix & enhancement
Date: Fri, 06 Mar 2009 21:59:08 +0100
Lines: 58
Message-ID: <gos2qs$10a$1@ger.gmane.org>
Reply-To: joerg.schaible@gmx.de
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8Bit
Mail-Copies-To: never
User-Agent: KNode/0.10.9
Sender: news <news@ger.gmane.org>

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.

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?

- J�rg


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