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 :)
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]
