commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Inger, Matthew" <In...@Synygy.com>
Subject [Configuration] IniFile
Date Wed, 03 Mar 2004 19:09:41 GMT
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


Mime
View raw message