commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <ebo...@micropole-univers.com>
Subject Re: [Configuration] IniFile
Date Thu, 04 Mar 2004 12:02:38 GMT
The CompositeConfiguration solution will not work because the same key 
can be used under different sections. I see one issue with the 
prefixing: the dot is allowed in the section name, that may break the 
file when it is saved. For example given the following file:

[xxx.yyy]
key=value

After reading the file we would have this property:
xxx.yyy.key=value

If we assume the part of the key before the first dot is the section 
name, then on saving we would get:

[xxx]
yyy.key=value

Prefixing the key with the section name and its brackets may be a 
solution, but I don't know how it will work with subsets.

[section1]key1=value1
[section2]key2=value2


Also I've found some useful information regarding the ini file format:
http://cloanto.com/specs/ini.html

Existing ini file parsers in Java:
http://www.bebbosoft.de/api/de/bb/util/IniFile.html
http://unidata.ucar.edu/packages/dods/api/javaDocs/dods/util/iniFile.html
http://www.ubique.ch/code/inieditor/javadoc/ch/ubique/inieditor/IniEditor.html

Emmanuel Bourg


Inger, Matthew wrote:

> I don't particularly like the idea of adding additional methods onto
> concrete classes.  I would rather use the "subset" method of the
> configuration interface if someone wants to deal with a particular
> section.  Note however, that when you use "subset", any changes
> in the new configuration don't affect the parent.  Someone would
> still have to go back and change the parent.
> 
> I prefer the idea of prefixing the section name.  It's a simpler
> implementation (though i could easily come up with a bigger hierarchy
> complete with some sort of NamedConfiguration interface and so forth)
> where calling subset and changing the subset would affect the parent.
> 
> 
> 
> IniFileConfiguration conf = ...;
> Configuration sub = null;
> String sectionName = null;
> Iterator it = conf.getSectionNames();
> while (it.hasNext()) {
>    sectionName = (String)it.next();
>    sub = conf.subset(sectionName);
> }
> 
> -----Original Message-----
> From: Emmanuel Bourg [mailto:ebourg@micropole-univers.com]
> Sent: Wednesday, March 03, 2004 2:27 PM
> To: Jakarta Commons Developers List
> Subject: Re: [Configuration] IniFile
> 
> 
> That might be interesting, I see 2 approaches, either prefix the keys 
> with the section name, thus your example would produce the following 
> properties:
> 
> section1.key1=value1
> section2.key2=value2
> 
> 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 [mailto:Joerg.Schaible@Elsag-Solutions.com]
>>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
>>>>factory. 
>>>>
>>>>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: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

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


Mime
View raw message