You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Emmanuel Bourg <eb...@apache.org> on 2008/02/17 15:10:19 UTC
[configuration] What changes in Commons Configuration 2.0 ?
Hi,
I'd like to open the discussion on the changes we'll implement on the
2.x branch. Here is a list of the things I have in mind :
Cleanup
- Remove ConfigurationFactory, its use is deprecated since the
introduction of ConfigurationBuilder. This removal will allow us to drop
the dependency on Digester.
- Remove the deprecated classes and methods
(HierarchicalXMLConfiguration and several methods here and there)
- It may be possible to drop the dependency on JXPath since Java 5 comes
with it's own XPath implementation (in the javax.xml.xpath package). I
wrote a quick test and I've been able to query a
HierarchicalConfiguration with the standard classes. I'll try to
implement an ExpressionEngine from this prototype.
Refactoring
- New package name, with no version number please. I suggest
org.apache.commons.config
- Merge the methods of DataConfiguration into the Configuration
interface, and remove the methods that can be generified. For example
there is no need for getBigDecimalList(key, defaultValue) if
getList(String key, List<T> defaultValue) is available.
- Make all configurations hierarchical by default, that means merging
the methods of HierarchicalConfiguration into the Configuration interface.
- All configurations being hierarchical, the Configuration becomes the
tree node. This is similar to the Preferences API. SubsetConfiguration
can be abandoned.
- Adopt the concept of flush() / sync() from the Preferences API to make
all configurations persistence-aware. This would allow us to merge
FileConfiguration with Configuration and greatly simplify the existing
code. This will allow to save the changes in a DatabaseConfiguration in
an efficient way with the same save() or sync() method used for the file
based configurations.
- Should we turn Configuration into an abstract class to allow the
addition of new methods later ?
- Make the file based configurations reloadable by default. The
FileChangedReloadingStrategy replace the InvariantReloadingStrategy as
the default strategy.
New features
- Bridge with the Preferences API, that means implementing a
PreferencesConfiguration class to use a Preferences as a Configuration,
and a ConfigurationPreferences do to the opposite.
- Introduce the Locators ? The use of a locator should remain optional
to keep the API easy to use.
- Implement a pluggable conversion mechanism for the values stored in
the configurations. This may rely on Morph or Beanutils. This is a low
priority though.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] What changes in Commons Configuration 2.0 ?
Posted by Emmanuel Bourg <eb...@apache.org>.
Jörg Schaible a écrit :
> Another change:
>
> - Get rid of the current list handling
>
> Currently any value is parsed for list elements and if the list delimiter is found, it will return only the first value. IMHO a list should only be returned if 'getList' is called (with an optional delimiter parameter), but a call to 'getString' should return the complete value.
This feature has been frequently requested. I wonder if both behaviors
should be supported with an optional flag.
Regarding the various flags in use (throwExceptionOnMissing,
delimiterParsingDisabled), maybe they could be gathered in a class, let
say ConfigurationOptions, to allow the addition of other flags without
touching the Configuration interface.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [configuration] What changes in Commons Configuration 2.0 ?
Posted by Jörg Schaible <Jo...@Elsag-Solutions.com>.
Oliver Heger wrote:
> In most points I agree. Some comments below:
>
> Emmanuel Bourg schrieb:
[snip]
>> - New package name, with no version number please. I suggest
>> org.apache.commons.config
> I prefer going with the commons standards here. I am against a config
> package because it is unrelated to the existing configuration
> package. A package name of configuration2 shows that the API is
> evolving.
+1. Especially since I cannot remember, when I typed a package name the last time. Usually this is done by my IDE.
[snip]
Another change:
- Get rid of the current list handling
Currently any value is parsed for list elements and if the list delimiter is found, it will return only the first value. IMHO a list should only be returned if 'getList' is called (with an optional delimiter parameter), but a call to 'getString' should return the complete value.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] What changes in Commons Configuration 2.0 ?
Posted by Emmanuel Bourg <eb...@apache.org>.
Oliver Heger a écrit :
>> - New package name, with no version number please. I suggest
>> org.apache.commons.config
> I prefer going with the commons standards here. I am against a config
> package because it is unrelated to the existing configuration package. A
> package name of configuration2 shows that the API is evolving.
Well, the evolution of the component is mainly materialized by the
change of the major revision number, not by the package name. Changing
the package is just a solution to avoid conflicts.
Btw I'm less concerned about the package name than the artifactId.
>> - Should we turn Configuration into an abstract class to allow the
>> addition of new methods later ?
> Interfaces are fine IMO. For instance, they allow for a better
> testability using mock objects.
Between additional features and improved testability I'd go for the
features. Is using a mock for a Configuration actually useful ? It seems
easier to use a BaseConfiguration directly.
> I am not that happy with the current approach to reloading. Maybe we can
> come up with something better.
I agree, we need an active reloading mechanism to be able to fire a
change notification as soon as the file has been touched.
> The current way of dealing with files and file names is complex, and the
> API is bloated with lots of get and set methods. We have now the chance
> of changing this. So why not go for locators? This will be a hard break
> for configuration 1 users, but on the long run I think we are better off.
I think it's important to keep a simple way of instantiating a
Configuration directly from a File or an URL without using a locator.
The string based constructors could use a default locator.
Regarding the get/setters I would happily kill the filename and basepath
accessors.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] What changes in Commons Configuration 2.0 ?
Posted by Oliver Heger <ol...@oliver-heger.de>.
In most points I agree. Some comments below:
Emmanuel Bourg schrieb:
> Hi,
>
> I'd like to open the discussion on the changes we'll implement on the
> 2.x branch. Here is a list of the things I have in mind :
>
>
> Cleanup
>
> - Remove ConfigurationFactory, its use is deprecated since the
> introduction of ConfigurationBuilder. This removal will allow us to drop
> the dependency on Digester.
+1
>
> - Remove the deprecated classes and methods
> (HierarchicalXMLConfiguration and several methods here and there)
+1
>
> - It may be possible to drop the dependency on JXPath since Java 5 comes
> with it's own XPath implementation (in the javax.xml.xpath package). I
> wrote a quick test and I've been able to query a
> HierarchicalConfiguration with the standard classes. I'll try to
> implement an ExpressionEngine from this prototype.
Let's test this out. However I would like to modify the ExpressionEngine
interface slightly to offer more features.
>
>
> Refactoring
>
> - New package name, with no version number please. I suggest
> org.apache.commons.config
I prefer going with the commons standards here. I am against a config
package because it is unrelated to the existing configuration package. A
package name of configuration2 shows that the API is evolving.
>
> - Merge the methods of DataConfiguration into the Configuration
> interface, and remove the methods that can be generified. For example
> there is no need for getBigDecimalList(key, defaultValue) if
> getList(String key, List<T> defaultValue) is available.
For the extended data types we can have a generic
<T> T get(String property, Class<T> valueClass)
method. This can be combined with the pluggable converters mentioned below.
>
> - Make all configurations hierarchical by default, that means merging
> the methods of HierarchicalConfiguration into the Configuration interface.
+1.
I have some ideas for hierarchical configurations that do not operate on
ConfigurationNodes and thus do not keep all their properties in memory.
A PreferencesConfiguration or an improved JNDIConfiguration could be
based on this.
>
> - All configurations being hierarchical, the Configuration becomes the
> tree node. This is similar to the Preferences API. SubsetConfiguration
> can be abandoned.
I am not convinced by this. Will have to see how this looks like in
practice.
>
> - Adopt the concept of flush() / sync() from the Preferences API to make
> all configurations persistence-aware. This would allow us to merge
> FileConfiguration with Configuration and greatly simplify the existing
> code. This will allow to save the changes in a DatabaseConfiguration in
> an efficient way with the same save() or sync() method used for the file
> based configurations.
+1
>
> - Should we turn Configuration into an abstract class to allow the
> addition of new methods later ?
Interfaces are fine IMO. For instance, they allow for a better
testability using mock objects.
>
> - Make the file based configurations reloadable by default. The
> FileChangedReloadingStrategy replace the InvariantReloadingStrategy as
> the default strategy.
I am not that happy with the current approach to reloading. Maybe we can
come up with something better.
>
>
> New features
>
> - Bridge with the Preferences API, that means implementing a
> PreferencesConfiguration class to use a Preferences as a Configuration,
> and a ConfigurationPreferences do to the opposite.
>
> - Introduce the Locators ? The use of a locator should remain optional
> to keep the API easy to use.
The current way of dealing with files and file names is complex, and the
API is bloated with lots of get and set methods. We have now the chance
of changing this. So why not go for locators? This will be a hard break
for configuration 1 users, but on the long run I think we are better off.
>
> - Implement a pluggable conversion mechanism for the values stored in
> the configurations. This may rely on Morph or Beanutils. This is a low
> priority though.
>
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org