Hi, Am 23.03.2014 18:17, schrieb dont_know: > Hi Martin, > > I hope you haven't missunderstood me: the behaviour of > DefaultConfigurationBuilder is ugly, not your solution ;) > > But I think you have overlooked the second important part in the > config.xml -> the definition of a ReloadStrategy for the referenced > properties. This did the trick and I want my queen back :)
I don't play Chess, but I am also not sure whether I understand your solution. So, your complaint is that DefaultConfigurationBuilder reads the source file too often, right? Well, we could add logic to avoid that the same configuration source is read multiple times. However, loading one configuration file ten times in a builder definition is certainly not the intended use case. Typically, you read different configuration files, and then the builder has no other chance than reading them one by one. In your scenario you are better off by creating the CombinedConfiguration yourself from a configuration file read manually. IIUC, your problem was that no reloads happened when the source file was changed by another process. Therefore, you had to re-create the configuration from the builder each time you want to access it. By setting the forceReloadCheck flag, this is no longer necessary because reloads are now detected. Is this correct? Oliver > > Am 22.03.2014 23:55, schrieb Martin Gainty: > >> Date: Sat, 22 Mar 2014 22:39:14 +0100 >> From: [email protected] >> To: [email protected] >> Subject: Re: [configuration] Calling getConfiguration on >> DefaultConfigurationBuilder more than once permitted >> >> Hi Martin, >> >> I found a solution which fits my requirements without this ugly >> behaviour as described before. The trick is to configure the reloading >> strategy and force the reload checking in "config.xml": >> <?xml version="1.0" encoding="ISO-8859-1" ?> >> >> <configuration> >> <header> >> <result forceReloadCheck="true"/> >> </header> >> > MG>lets find out what forceReloadCheck and what it does > MG>/commons-configuration>grep -r -l forceReloadCheck *.* > .\src\main\java\org\apache\commons\configuration\CombinedConfiguration.java > .\target\classes\org\apache\commons\configuration\CombinedConfiguration.class > > > MG>forceReloadCheck has NO effect on > DefaultConfigurationBuilder.getConfiguration() > protected CombinedConfiguration createAdditionalsConfiguration( > CombinedConfiguration resultConfig) > { > CombinedConfiguration addConfig = > new CombinedConfiguration(new UnionCombiner()); //this will > STILL pull UNION of entities > > addConfig.setDelimiterParsingDisabled(resultConfig > .isDelimiterParsingDisabled()); > addConfig.setForceReloadCheck(resultConfig.isForceReloadCheck()); > addConfig.setIgnoreReloadExceptions(resultConfig > .isIgnoreReloadExceptions()); > return addConfig; > } > MG>if this was chess ..i have just taken your queen > MG>your move.. > >> </configuration> >> >> That just made my day :) >> >> Thanks for your effort >> Stefan >> >> Am 22.03.2014 02:17, schrieb Martin Gainty: >> > >> > >> > >> >> Date: Fri, 21 Mar 2014 22:45:29 +0100 >> >> From: [email protected] >> >> To: [email protected] >> >> Subject: [configuration] Calling getConfiguration on >> DefaultConfigurationBuilder more than once permitted >> >> >> >> Hi, >> >> >> >> is it permitted to call getConfiguration more than once on the same >> >> instance of DefaultConfigurationBuilder like this: >> >> >> >> DefaultConfigurationBuilder builder = new >> DefaultConfigurationBuilder(); >> >> builder.setFile(new File("config.xml")); >> >> Configuration config = builder.getConfiguration(true); >> >> config = builder.getConfiguration(true); >> >> config = builder.getConfiguration(true); >> >> ... >> >> >> >> The config.xml looks like this: >> >> <?xml version="1.0" encoding="ISO-8859-1" ?> >> >> >> >> <configuration> >> >> <properties fileName="test.properties" config-at="a"/> >> >> <properties fileName="test.properties" config-at="b"/> >> >> <properties fileName="test.properties" config-at="c"/> >> >> <properties fileName="test.properties" config-at="d"/> >> >> <properties fileName="test.properties" config-at="e"/> >> >> <properties fileName="test.properties" config-at="f"/> >> >> <properties fileName="test.properties" config-at="g"/> >> >> <properties fileName="test.properties" config-at="h"/> >> >> <properties fileName="test.properties" config-at="i"/> >> >> <properties fileName="test.properties" config-at="j"/> >> >> </configuration> >> >> >> >> and the referenced file "test.properties" contains: >> >> a=a >> >> b=b >> >> c=c >> >> >> >> I asked this question, because with the first call of getConfiguration >> >> the "test.properties"-file is read 10 times (once for every >> >> "config-at"), with the second call 20 times, with the third call 30 >> >> times and so on. So in the end the program slows down and after 100 >> >> calls it needs 200ms to read the properties. >> > >> > MG>builder.getConfiguration(true) a Union between one DB Table and >> another DB Table >> > MG>if you want to 'merge' 2 groups together I suggest using >> OverrideCombiner >> > MG>ConfigurationNode combine(ConfigurationNode node1, >> ConfigurationNode node2) >> > MG> >> http://www.docjar.com/html/api/org/apache/commons/configuration/tree/OverrideCombiner.java.html >> >> >> I'm a little bit confused because my idea was to instantiate >> >> DefaultConfigurationBuilder for performance reasons only once (as a >> >> Singleton) and call getConfiguration subsequently to read "fresh" >> >> properties. >> >> >> >> Thanks >> >> Stefan >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
