commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Szokol <szt...@gmail.com>
Subject [configuration] FileChangedReloadingStrategy problem
Date Fri, 16 Sep 2005 14:38:44 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message