commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [configuration] Design discussion
Date Tue, 29 Jan 2013 00:32:28 GMT
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.

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.

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-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
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message