commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [configuration] Plan for 2.0
Date Sat, 08 Sep 2012 16:45:47 GMT
If you are going to break compatibility the package names need to be changed.

I really dislike CombinedConfiguration.  Having the combined nodes point into other configuration
nodes makes reloading fragile which is why it now copies nodes.  This means that a DynamicCombinedConfiguration
that has a common default node will have as many copies of the default node as there are instances
of the CombinedConfiguration.  This uses a large amount of memory.  I really wish DefaultConfigurationBuilder
worked on an AggregateConfiguration, but that isn't designed to support XML.

The bottom line is that we should think about the classes and interfaces that are there and
create a more rational hierarchy. For example, DefaultConfigurationBuilder should be able
to create any kind of combination, which means it should work with an Interface, not a concrete

I still believe HierarchicalConfiguration should be a base Interface, not a Class.

The nonsense with attribute splitting and delimiter parsing needs to go away.


On Sep 7, 2012, at 12:46 PM, Oliver Heger wrote:

> Hi all,
> the pom was updated to make 2.0-SNAPSHOT the current development version. This means
we are free to implement major changes without having to enforce binary backwards compatibility.
> The question is: What are the goals for version 2.0? I would recommend to define a clear
focus so that the next release will not take too long. Obviously there are already people
waiting for a [configuration] version compatible with [lang3].
> Some points I have in mind are the following ones:
> - Switch to [lang3]. This is the main reason for going to version 2.0 because this cannot
be done in a binary compatible way.
> - Improve thread safety and concurrent implementations in general.
> - Rework reloading. This is related to the previous point because I think the tight coupling
of the current reloading implementation is one of the root causes making the implementation
of thread-safe configurations so hard.
> - Have a look at older Jira tickets which have been postponed because they would break
binary compatibility.
> Any other points, wishes, or opinions? We should discuss the points separately when it
comes to their implementation.
> Oliver
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message