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.
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" <oliver.he...@oliver-heger.de
<mailto: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
<mailto:user-unsubscr...@commons.apache.org>
For additional commands, e-mail: user-h...@commons.apache.org
<mailto:user-h...@commons.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
<mailto:user-unsubscr...@commons.apache.org>
For additional commands, e-mail: user-h...@commons.apache.org
<mailto:user-h...@commons.apache.org>
