[configuration] FileChangedReloadingStrategy problem

[Thomas Szokol <sz...@gmail.com>]

Hello!


I'm Szokol Tamás and I encountered the following problem while using 
FileChangedReloadingStrategy
and I ask you to comment it and help me in this topic.

I created an application which uses a property file for configuration 
purposes. The application 
behaves different ways according to the configuration. I handle the 
administration of this file 
by using the PropertiesConfiguration class. It works fine from the 
application.

The problem occured when I started to unit test the application using JUnit. 
I test the application's
functionality whether it behaves the expected way according to the content 
of the configuration file.
To achieve this I have to change the configuration runtime in the test cases 
and inspect the expected and
the actual responses. So I have to use the FileChangedReloadingStrategy on 
my application and test side to 
notify that the configuration has been changed by the test classes.
In this case the following strange thing happens: I can normally read the 
configuration in the test case, 
find the values of the keys I use, but after the first time I use the 
setProperty function on the test 
side to change the configuration the whole content of the configuration file 
will be terminated, and I 
end up having an empty property file.

My observations were the following while I examined the conditions of this 
problem:

1. I tested the FileChangedReloadingStrategy in two simple dummy POJOs. Both 
of them use PropertiesConfiguration
with FileChangedReloadingStrategy. I set two different reloading time 
intervals. ClassA reads a property, goes to
sleep, ClassB sets a new value for the property ClassA has just read, ClassB 
goes to sleep, ClassA wakes up, reads
the value of the property and it is the new one, ClassB wakes up, reads the 
value of the property and it is the new one,
end of story. so FileChangedReloadingStrategy works fine in this scenario.

2. If I didn't use FileChangedReloadingStrategy the handling of the property 
file was 100% correct. 
But of course in this case the application had no idea about the changes of 
the property file.

3. If I didn't use JUnit - so I didn't extend TestCase - and used 
PropertiesConfiguration with 
FileChangedReloadingStrategy the handling of the property file was 100% 
correct. But in this case testing
is harder without JUnit.

4. Using or not using auto save functionality does not effect the result, it 
doesn't work anyway.

I checked the mailing list archive of jakarta commons and I didn't find any 
hints I could use.

I ask you to help me solving this problem.

Sorry about the long message, I tried to be precise.


Thank you for your attention and your time.

Best regards,
Szokol Tamás

Re: [configuration] FileChangedReloadingStrategy problem

[Emmanuel Bourg <eb...@apache.org>]

Hi Tamás, I'm not sure to understand your issue, but it looks like you
are testing the reloading mechanism which is already covered by our unit
tests. I would advise writing a different test using a specific
configuration file for each behavior of your application depending on
the configuration. The reloading is quite tricky to test properly, you
can rely on our tests instead of writing your own.

Emmanuel Bourg



Thomas Szokol wrote:
> Hello!
> 
> 
> I'm Szokol Tamás and I encountered the following problem while using 
> FileChangedReloadingStrategy
> and I ask you to comment it and help me in this topic.
> 
> I created an application which uses a property file for configuration 
> purposes. The application 
> behaves different ways according to the configuration. I handle the 
> administration of this file 
> by using the PropertiesConfiguration class. It works fine from the 
> application.
> 
> The problem occured when I started to unit test the application using JUnit. 
> I test the application's
> functionality whether it behaves the expected way according to the content 
> of the configuration file.
> To achieve this I have to change the configuration runtime in the test cases 
> and inspect the expected and
> the actual responses. So I have to use the FileChangedReloadingStrategy on 
> my application and test side to 
> notify that the configuration has been changed by the test classes.
> In this case the following strange thing happens: I can normally read the 
> configuration in the test case, 
> find the values of the keys I use, but after the first time I use the 
> setProperty function on the test 
> side to change the configuration the whole content of the configuration file 
> will be terminated, and I 
> end up having an empty property file.
> 
> My observations were the following while I examined the conditions of this 
> problem:
> 
> 1. I tested the FileChangedReloadingStrategy in two simple dummy POJOs. Both 
> of them use PropertiesConfiguration
> with FileChangedReloadingStrategy. I set two different reloading time 
> intervals. ClassA reads a property, goes to
> sleep, ClassB sets a new value for the property ClassA has just read, ClassB 
> goes to sleep, ClassA wakes up, reads
> the value of the property and it is the new one, ClassB wakes up, reads the 
> value of the property and it is the new one,
> end of story. so FileChangedReloadingStrategy works fine in this scenario.
> 
> 2. If I didn't use FileChangedReloadingStrategy the handling of the property 
> file was 100% correct. 
> But of course in this case the application had no idea about the changes of 
> the property file.
> 
> 3. If I didn't use JUnit - so I didn't extend TestCase - and used 
> PropertiesConfiguration with 
> FileChangedReloadingStrategy the handling of the property file was 100% 
> correct. But in this case testing
> is harder without JUnit.
> 
> 4. Using or not using auto save functionality does not effect the result, it 
> doesn't work anyway.
> 
> I checked the mailing list archive of jakarta commons and I didn't find any 
> hints I could use.
> 
> I ask you to help me solving this problem.
> 
> Sorry about the long message, I tried to be precise.
> 
> 
> Thank you for your attention and your time.
> 
> Best regards,
> Szokol Tamás
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org