Do we need better Javadocs to make this obvious?
Gary
On Nov 27, 2016 7:02 AM, "Oliver Heger" <oliver.he...@oliver-heger.de>
wrote:
> Hi,
>
> Am 25.11.2016 um 22:55 schrieb Garret Wilson:
>
>> I'm reading the documentation for the new commons-configuration 2.x. I
>> have a simple need: load a configuration file from a properties file,
>> reload it when the file changes, and make the configuration thread-safe
>> for reading.
>>
>> From the documentation I understand that I shouldn't keep the
>> Configuration object around, because it may be reloaded if the file
>> changes. Instead I should keep a ConfigurationBuilder around. So my
>> application's getConfiguration() would look like this:
>>
>> public Configuration getConfiguration() {
>> return configurationBuilder.getConfiguration();
>> }
>>
>> But I need it to be thread-safe. So I do this:
>>
>> public Configuration getConfiguration() {
>> Configuration configuration=configurationBuilder.getConfiguration();
>> configuration.setSynchronizer(new ReadWriteSynchronizer());
>> return configuration;
>> }
>>
>> Oops! It turns out that we don't know if the builder returns the same
>> configuration or a new configuration, so we could be swapping out the
>> synchronizer on the same configuration. That introduces a race condition
>> and defeats the thread safety!
>>
>> So are we expected to keep a separate synchronizer around and make sure
>> the new/existing configuration uses it?
>>
>> private final Synchronizer synchronizer = new ReadWriteSynchronizer();
>>
>> public Configuration getConfiguration() {
>> Configuration configuration=configurationBuilder.getConfiguration();
>> configuration.setSynchronizer(synchronizer);
>> return configuration;
>> }
>>
>> Wow, that's getting complicated. The problem is that Apache Commons
>> Configuration2 recommends that the builder be the ultimate source of the
>> configuration, yet it associates the syncrhonizer with the actual
>> configuration instance. Shouldn't we set the synchronizer on the builder
>> and let it manage the synchronizer of the new configurations? Or do you
>> want each configuration to potentially have different synchronizers? But
>> is that realistic---would synchronized and unsynchronized configurations
>> play well together if they are backed by the same builder? I'm trying to
>> understand what the expected usage is.
>>
>
> you configure the builder to set the correct synchronizer on newly created
> Configuration objects. To achieve this, call the builder's configure()
> method with a parameters object. Focused on the synchronizer, this looks as
> follows:
>
> Synchronizer sync = ...;
> Parameters params = new Parameters();
> BasicConfigurationBuilder<PropertiesConfiguration> builder =
> new BasicConfigurationBuilder<PropertiesConfiguration>(
> PropertiesConfiguration.class)
> .configure(params.basic()
> .setSynchronizer(sync));
>
> Just insert your type parameters for the configuration type. All
> properties configured this way are automatically set on the Configuration
> each time a new instance is created.
>
> Oliver
>
>
>> Garret
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
>> For additional commands, e-mail: user-h...@commons.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>
