Am 29.01.2013 01:32, schrieb Ralph Goers:
Sure - But as I've worked with CombinedConfiguration I became less enthralled
with it. The problem I had with the DynamicCombinedConfiguration was that
every CombinedConfiguration has to have its own copy of all the configurations.
Attempting to share a configuration led to all kinds of corruption when the
file was updated and the tree was modified. I really wanted to do the same
thing with CompositeConfiguration but since it didn't officially support XML
and doesn't have a builder I didn't get around to it.
I don't have a bright idea how to handle this. I hope, situation gets a
bit better when reloading is done differently; then configuration data
cannot change completely at any time. It is still on my list for 2.0 to
implement a mechanism to make configurations optionally thread-safe.
Hopefully, this leads to a solution for CombinedConfiguration, too.
Ultimately, I would prefer that there only be one ConfigurationBuilder and that
its end result be a Configuration, not a CombinedConfiguration. Underneath
that there could, of course, be various flavors of builders but ideally the
user wouldn't need to be bothered with them.
Sounds good. Currently I am following a bottom-up approach, i.e. I
create the various builders first. It should be possible to implement a
'meta' builder on top later.
Oliver
Ralph
On Jan 28, 2013, at 1:10 PM, Oliver Heger wrote:
(From time to time I am going to post an update about the progress I have made
so that everybody who is interested can comment.)
Just finished reworking MultiFileConfiguration to use the new builder approach.
There is now a MultiFileConfigurationBuilder class offering pretty much the
same functionality plus that it can deal with arbitrary file-based
configurations.
The class now also works well together with CombinedConfigurationBuilder in the
same way the old integration was with DefaultConfigurationBuilder, i.e. a
DynamicCombinedConfiguration is used to ensure that a new CombinedConfiguration
is constructed every time the file pattern changes.
@Ralph: Maybe, as the original author, you find the time to have a short look
to verify that no features were lost?
CombinedConfigurationBuilder should now provide the same functionality as
DefaultConfigurationBuilder. With slight exceptions it can process the same
configuration definition files. So I plan to remove DefaultConfigurationBuilder
shortly.
Oliver
Am 05.01.2013 16:48, schrieb Oliver Heger:
Hi Jörg,
Am 04.01.2013 17:47, schrieb Jörg Schaible:
Hi Oliver,
Oliver Heger wrote:
Hi,
recently I have worked on code regarding the creation of Configuration
objects and reloading support. I have created two Jira tickets [1, 2]
with a description of the problems I see in the current design.
The code in SVN (mainly in the new builder package) should be sufficient
to get a good impression about the direction I would like to go. It is
far more than a pure proof of concept.
However, following this road means some significant changes in the
design and in the way client code uses our classes. Therefore, I would
really appreciate feedback from other committers also interested in this
component.
My main question is: Can we replace the reloading mechanisms available
in 1.x by an approach based on builders as currently implemented in
trunk (e.g. classes
o.a.c.c.builder.ReloadingFileBasedConfigurationBuilder,
o.a.c.c.reloading.ReloadingController)? If the answer is 'yes', we could
go forward and significantly simplify most of the file-based
configuration implementations.
Thanks
Oliver
[1] https://issues.apache.org/jira/browse/CONFIGURATION-519
[2] https://issues.apache.org/jira/browse/CONFIGURATION-520
simply go-on with these changes. IMHO it looks good and since
separation of
concern leads here to significant code simplification, it's for the
best of
us devs and also for our users in the long term. Especially since the new
approach brings also improved functionality.
Thanks for your feedback. Will do!
Oliver
Cheers,
Jörg
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
