commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [Configuration] HierarchicalConfiguration in configuration2
Date Sat, 20 Dec 2008 15:32:34 GMT
Ralph Goers schrieb:
> On Dec 15, 2008, at 1:22 PM, Oliver Heger wrote:
>> Ralph Goers schrieb:
>>> On Dec 13, 2008, at 12:42 PM, Oliver Heger wrote:
>>> I don't think any dummy implementations are needed.  If 
>>> BaseConfiguration extended AbstractHierarchicalConfiguration instead 
>>> of AbstractFlatConfiguration it would need to override createNode to 
>>> disallow node creation and register the FlatNodeHandler . Other than 
>>> that what else would need to be done?
>> So you mean that AbstractFlatConfiguration is not needed as a base 
>> class for non-hierarchical configurations?
> Yes, Any code in it that is needed could move to BaseConfiguration.
>> Its main functionality is to provide support for creating the tree of 
>> configuration nodes on demand and keep it up-to-date. Derived classes 
>> can still operate on their native data structures, e.g. maps.
>> If you extend AbstractHierarchicalConfiguration directly, wouldn't you 
>> have to implement the handling of nodes yourself?
> I don't think so. The main reason is that a Flat configuration shouldn't 
> be able to have any child nodes so all that is needed is making sure 
> they can't be created.
>> But anyway, its a while since I deeply looked into these things. If 
>> you want to try something out, don't hesitate!
> OK. I haven't delved too deeply in this. All I've been doing really is 
> working on trunk and then trying to figure out how to port it to the 
> branch.
> Ralph
Just another point: There are other flat configuration implementations 
that do not extend BaseConfiguration, e.g. the web configurations or 
DatabaseConfiguration. AbstractFlagConfiguration was intended to serve 
as a common base class for all of these.


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

View raw message