Hi Oliver,
yes, you are right. My problem was that no reload happens when one or more of
the property files were changed. So I called getConfiguration on the
DefaultConfigurationBuilder to reload the properties. And this leads to heavy
file access because every call to getConfiguration adds ten file accesses
additionally per call:
first call -> 10 file accesses
second call -> 20 file accesses
third call -> 30 file accesses
100th call -> 1000 file accesses
By defining the forceReloadCheck flag and a ReloadStrategy this problem doesn't
occure anymore and I can use a single instance of Configuration which
automatically reflects the changed properties.
Unluckily the example with ten same property files was bad. In my real use case
I use references to ten different property files.
Stefan
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
