commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <>
Subject Re: [Configuration] IniFile
Date Wed, 03 Mar 2004 19:27:19 GMT
That might be interesting, I see 2 approaches, either prefix the keys 
with the section name, thus your example would produce the following 


or handle a .ini file as a composite configuration, with 1 configuration 
per section. A WindowsConfiguration class could be a subclass of 
CompositeConfiguration with additional methods for loading/saving the 
configuration, and adding a property under a specific section (something 
like setProperty(String section, String key, String value)).

Emmanuel Bourg

Inger, Matthew wrote:

> Any interest in an INI File configuration class?
> It would read a Windows style .ini file.  A sample:
> 	[Section1]
> 	key1=value1
> 	[Section2]
> 	key2=value2
> would produce the following properties:
> 	Section1/key1=value1
> 	Section2/key2=value2
> Unfortunately, empty sections would not be dealt with
> by the existing state of what i have.
> -----Original Message-----
> From: Jörg Schaible []
> Sent: Wednesday, March 03, 2004 8:35 AM
> To: Jakarta Commons Developers List
> Subject: RE: [Configuration] Standard DOM ?
> Emmanuel Bourg wrote on Wednesday, March 03, 2004 2:22 PM:
>>Jörg Schaible wrote:
>>>Well, this is not what I would like to have, again because of the
>>>dom4j dependency. I already have a
>>HierarchicalDOMConfiguration that
>>>is based on the w3c classes only. I just took the code from
>>>HierarchicalDOM4JConfiguration and replaced the relevant parts. The
>>>same could be done for a DOMConfiguration. To complete the DOM
>>>support a <dom> tag could be supported by the factory. Also the
>>>factory could be refactored so that the most functionality is in an
>>>abstract base class and the derived classes would add the supported
>>>tags. ConfigurationFactory would support anything contained in the
>>>configuration package (= backward compatibility) and the user could
>>>create his own factory with the elements he would like to use (and
>>>their dependencies). Additionally this would allow user-defined
>>>Configuration classes or the support of DatabaseConfiguration in the
>>>What do you think?
>>I don't know the motivations for using DOM4J, but using the standard
>>interfaces and removing a dependency is certainly interesting.
>>A pluggable extension mechanism for the ConfigurationFactory would be
>>nice too. 
> Do I have to consider something else concerning submission/donation of the
> code?
> Regards,
> Jörg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message