[
https://issues.apache.org/jira/browse/CONFIGURATION-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12931928#action_12931928
]
Dan Haynes commented on CONFIGURATION-425:
------------------------------------------
I did not have a chance to run the unit test you mentioned, but I did find a
workaround for the problem.
While I was trying to fix the code before, to be absolutely sure the file was
being updated I used FileUtils.forceDelete() on the destination file before
doing the file copy. I had hoped that the Linux version would pick up on the
file system change due to the delete. That didn't work, it did not reload the
properties file even though a 'cat' of the file showed that it had indeed been
completely replaced.
In the source of the unit test you supplied I happened to notice that it uses
file.delete() while I'm using FileUtils.forceDelete(). I changed my code to
use FileUtils.deleteQuietly() instead of FileUtilsforceDelete() and that makes
the difference!
File srcFile = new File(sourceFileName);
File destFile = new File(destFileName);
FileUtils.forceDelete(destFile); <-- this doesn't work
- the properties never gets reloaded
FileUtils.deleteQuietly(destFile); <-- this works, the
properties file is reloaded on the next access, as expected.
destFile.delete() <-- this doesn't work either, the
properties are never reloaded
FileUtils.copyFile(srcFile, destFile, false);
I also tried it using destFile.delete(). Strangely enough, this also fails.
Commons configuration does not notice that the properties file has been
modified (actually not just modified but completely replaced)
I have try/catches for all possible exceptions, I see no exception thrown when
using forceDelete() or delete() - and technically speaking it doesn't seem like
they should be needed since FileUtils.copyFile() replaces the contents. Again,
I verified that the properties file is updated by doing a 'cat' on the file
during the test and it shows the updated properties but for some reason commons
configuration never reloads the file.
If I externally use 'cp' to copy a new properties file into place it does
recognize the change and reloads the properties as it should.
I'll see if I can find the time to build commons-configuration on the Linux box
and run the unit tests, but it may be a while.
Thank you for your help!
> FileChangedReloadingStrategy works differently on Unix and Windows
> ------------------------------------------------------------------
>
> Key: CONFIGURATION-425
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-425
> Project: Commons Configuration
> Issue Type: Bug
> Components: File reloading
> Affects Versions: 1.6
> Environment: Windows 7 x64 and Ubuntu 10.04 Server
> Reporter: Dan Haynes
> Priority: Minor
>
> I created a unit test for a configuration class that uses commons
> configuration. It loads both a set of static properties and a set of dynamic
> properties, the latter uses FilechangeReloadingStragegy. The unit test copies
> a file containing an initial set of of dynamic properties (using commons-io
> FileUtils.copy()) , verifies the values are as expected and then copies an
> updated set of properties, sleeps longer than the refresh delay and then
> verifies the new values are in place.
> On WIndows it works as expected. It recognizes that FileUtils.copy() has
> replaced the dynamic.properties file with an updated version and it loads the
> new property values.
> On Linux, nothing I do makes it recognize that the file has been replaced
> except by actually opening a shell and editing the dynamic.properties values.
> Then it works as expected.
> This may well be my lack of understanding of some Unix filesystem behavior
> but it seems like FilechangeReloadingStrategy should notice the change to the
> file one way or the other.
> The unit test looks like so:
> {code}
> final ConfigurationManager cm = new
> StandardConfigurationManager(staticTestPropertiesFileName,
> dynamicTestPropertiesFileName);
> /*
> * Initialize the configuration manager. This should read all
> the initial values.
> */
> cm.init();
> Assert.assertEquals(System.getProperty("java.user"),
> cm.retrieveUserName());
> /*
> * Verify that the static properties were read.
> */
> Assert.assertEquals("1.00", cm.retrieveVersionId());
> /*
> * Verify that the initial values for the dynamic properties
> were read.
> */
> Assert.assertEquals(100, cm.retrieveMaxConcurrentLogons());
> if (copyFile(updatedConfigFileName,
> dynamicTestPropertiesFileName))
> {
> /*
> * The default update window for Apache commons
> configuration file reload strategy is 5 seconds
> * so wait more than 5 seconds to ensure the new value
> will be read.
> */
> log.info("Sleeping until configuration refresh delay
> has passed");
> sleep(6000L);
> log.info("Woke, resuming test, maxConcurrentLogons = "
> + cm.retrieveMaxConcurrentLogons());
>
> /*
> * Verify that the property was updated to the expected
> new value.
> */
> >>> this fails every time on Linux: Assert.assertEquals(1,
> >>> cm.retrieveMaxConcurrentLogons());
> }
> else
> {
> Assert.fail("Couldn't copy updated test properties
> file");
> }
> {code}
> I've tried everything I could think of to trigger the reload strategy. After
> calling FileUtils.copy() on the file I added a FileUtils.touch() on the
> destination file. That didn't work so I added a "Process process =
> runtime.exec("touch " + destFile.getAbsolutePath());" to be absolutely 100%
> certain the file timestamp is being updated. It gets updated, but the
> reloading strategy never recognizes it.
> I googled and searched the JIRA incidents and the only thing I can find that
> looks similar are some references to a problem in V1.1 that was fixed long
> ago.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
