commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Inger, Matthew" <In...@Synygy.com>
Subject RE: [Configuration] IniFile
Date Thu, 04 Mar 2004 16:08:37 GMT
I think what i'm planning on is the following:

IniSectionConfiguration -
 extends BaseConfiguration, and doesn't really do much else
 except add a name attribute with a getter, and a save method
 to write the section to an output stream

IniFileConfiguration - 
  extends BaseConfiguration.  It contains a map, whose
  key is section name, and value is an IniSectionConfiguration
  object.  There will be getSection(String name) method which returns
  an IniSectionConfiguration.  The existing "subset" method will delegate
  to the getSection method.

  From the perspective of IniFileConfiguration keys are represented as:

       [section_name]keyName

  All of the get,add,clear, etc... methods will parse the key above and
  find the correct section, and delegate the call to that section.

I think this is the cleanest solution.  Thoughts?

-----Original Message-----
From: Emmanuel Bourg [mailto:ebourg@micropole-univers.com]
Sent: Thursday, March 04, 2004 7:03 AM
To: Jakarta Commons Developers List
Subject: Re: [Configuration] IniFile


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.ht
ml

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

---------------------------------------------------------------------
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