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
yet):
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
queried:
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.
Oliver
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 class.
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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
