Re: [configuration] tension between auto-loading and synchronization

[Oliver Heger]

Am 27.11.2016 um 18:14 schrieb Garret Wilson:
> Thanks for clearing this up, Oliver!
> 
> I was going straight from the documentation. On the page
> https://commons.apache.org/proper/commons-configuration/userguide/howto_concurrency.html
> I can't find anything about setting up the builder parameters.
> 
> So I'm extremely happy to learn that you can configure the builder with
> a synchronizer. So I guess the "tension" now is that part of the
> documentation says, "it's better to use a builder than the configuration
> itself, especially if you want auto-loading", and then the part that
> actually talks about synchronization seems to favor working with the
> configuration and doesn't even mention that I can set the synchronizer
> on the builder.
> 
> At the very least
> https://commons.apache.org/proper/commons-configuration/userguide/howto_concurrency.html
> should mention the configuration params.

I will try to make it clearer.

Oliver

> 
> Cheers,
> 
> Garret
> 
> 
> On 11/27/2016 8:58 AM, Gary Gregory wrote:
>>
>> Do we need better Javadocs to make this obvious?
>>
>> Gary
>>
>>
>> On Nov 27, 2016 7:02 AM, "Oliver Heger" > > 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 builder =
>> new BasicConfigurationBuilder(
>> 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
>> 

Re: [configuration] tension between auto-loading and synchronization

[Gary Gregory]

Do we need better Javadocs to make this obvious?

Gary

On Nov 27, 2016 7:02 AM, "Oliver Heger" 
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 builder =
> new BasicConfigurationBuilder(
> 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
>
>

Re: [configuration] tension between auto-loading and synchronization

[Oliver Heger]

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 builder =
new BasicConfigurationBuilder(
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

[configuration] tension between auto-loading and synchronization

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


Garret

P.S. Please reply-all, as I'm not yet subscribed to the list.

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[configuration] tension between auto-loading and synchronization

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


Garret

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org