commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] Plan for 2.0
Date Sat, 08 Sep 2012 19:04:17 GMT
Am 08.09.2012 18:45, schrieb Ralph Goers:
> 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.

One proposal for dealing with reloading in future (not fully thought out 

I would like to make builders a more central concept. Rather than 
creating configuration objects using the new operator (which is btw 
currently problematic for file-based configurations because many of 
their constructors call protected methods to be overridden by 
subclasses), instances should be obtained through builders.

Client code would store the builder rather than the configuration 
object. Each time access to the configuration is needed, the builder is 

Configuration conf = builder.getConfiguration();
// do something with conf

Then reloading can be moved from the configuration to the builder. There 
can be reloading-aware builder implementations which check whether a new 
configuration has to be created. Otherwise, the same object is returned.

This approach has the following advantages:
- Configuration implementations can be simplified, the whole reloading 
logic can be removed. This code is not trivial, a whole bunch of methods 
contain checks whether reloading is required.
- Threading issues related to reloading can no longer occur inside 
configuration objects.
- Error handling can be improved. Currently, if reloading fails, a 
runtime exception is thrown, and the whole Configuration object is corrupt.
- There is better control when a reload can actually happen. As long as 
a client only operates on a Configuration object (without querying the 
builder), it can be sure that the content does not suddenly changes due 
to a reload operation.

The main drawback is that reloading is less transparent for clients. No 
reload will happen if a client keeps a reference to the Configuration 
without querying it from the builder.

Maybe this approach can also help with CombinedConfiguration. Existing 
instances would not be changed by a reload of one of its children. Only 
when querying the builder, a new instance is returned.


> 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.
> Ralph
> 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:

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

View raw message