Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <49B29F88.3070401@oliver-heger.de>
Date: Sat, 07 Mar 2009 17:23:36 +0100
From: Oliver Heger <oliver.heger@oliver-heger.de>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [configuration] Local lookup fix & enhancement
References: <gos2qs$10a$1@ger.gmane.org>
 <6782671B-0839-443B-920C-1453559399C4@dslextreme.com>
In-Reply-To: <6782671B-0839-443B-920C-1453559399C4@dslextreme.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

I am fine with both points and also agree with the comments of Ralph.

1) sounds that the current implementation is buggy - or at least
inconsistent; so this should really be improved.

2) seems to be an interesting extension of the lookups we have so far.
Here it would be really cool if you could also add some notes to the
user's guide; maybe just a small usage example.

Thanks
Oliver

Ralph Goers wrote:
> 
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


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