[ https://issues.apache.org/jira/browse/CONFIGURATION-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13068517#comment-13068517 ]
Bruno P. Kinoshita commented on CONFIGURATION-202: -------------------------------------------------- Just had the same problem using 1.6 as Michael. +1 for this feature :-) Seems like VFSFileSystem and VFSFileMonitorReloadingStrategy are not present in 1.6 version, only in trunk :-( Looking forward for the next release of commons-configuration, as well as the updates in Maven repository ;) Cheers, Bruno. > FileReloadingStrategy should run in a background thread > ------------------------------------------------------- > > Key: CONFIGURATION-202 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-202 > Project: Commons Configuration > Issue Type: Improvement > Components: File reloading > Reporter: Michael Echerer > Priority: Minor > Fix For: 1.7 > > > I tried to build an Observer pattern around the FileReloadingStrategy in order > to have my custom observers notified about configuration changes. > The idea was mainly to set each FileConfiguration's strategy (in a composite > configuration) to a custom ReloadingStrategy extending the > FileReloadingStrategy. That custom stategy is able to register observers which > should have an custom method called whenever the FileReloadingStrategy's > reloadingPerformed was called. Actually I changed reloadingPerformed to call > each registered observers' "update" method. > Actually this works pretty well, except one major flaw that I understood only > after reading the source... > The FileReloadingStrategy doesn't do anything on a regular (background thread) > basis itself, it is only called by AbstractFileConfiguration.reload(). > But reload() is only called if e.g. getProperty() is called. In effect this > means that my observer code only is made aware about any change in the > configuration "after" I try to access any property value. Of course, my > observer > has no way to know then that anything changed, if not accidentaly a property > was > accessed from somewhere else in the code. > Hence the current implementation of FileReloadingStrategy is okay, if one just > wants to have configurations automatically reloaded, but it doesn't seem > possible to have some custom code hooked into the mechanism in a proper way. > E.g. you want to get your code informed about any config change (here you > cannot > assume that you manually issue a getProperty() to toggle a reload() and > hopefully an update, you're lost. > An interesting use case for such a reloading would be to get informed about a > change by a background thread via an observer mechanism and then have the > observer e.g. reinitialize something. > My intention behind this was for example, to have log4j properties managed by > commons configuration, hook an observer into the reloading and reinitialize > the > logger with the properties of the configuration as soon as notified about a > change. (btw. I know log4j has a reloading... just not flexible enough) > Or take any other case where you like to get informed about a change and do > something with the reloaded properties. > Anyhow... Now that I, after inspecting the code, know how it does not ;-) > work, > I might try to code my own threaded strategy differently, probably integrating > an observer part by default. I'll let you know if and when there's code to > share. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira