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 Wed, 03 Mar 2004 23:01:03 GMT
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


Mime
View raw message