commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [configuration] Design discussion
Date Tue, 29 Jan 2013 20:42:36 GMT
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-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
>


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


Mime
View raw message