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