You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Inger, Matthew" <In...@Synygy.com> on 2004/03/03 20:09:41 UTC
[Configuration] IniFile
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
Re: [Configuration] IniFile
Posted by Emmanuel Bourg <eb...@micropole-univers.com>.
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