Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <432EAD9A.3010203@apache.org>
Date: Mon, 19 Sep 2005 14:22:50 +0200
From: Emmanuel Bourg <ebourg@apache.org>
User-Agent: Thunderbird 1.4 (Windows/20050908)
MIME-Version: 1.0
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Subject: Re: [configuration] FileChangedReloadingStrategy problem
References: <745c9a3a050916073810ff7866@mail.gmail.com>
In-Reply-To: <745c9a3a050916073810ff7866@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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