DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=37324>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37324 Summary: [configuration] FileReloadingStrategy should run in a background thread Product: Commons Version: unspecified Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Configuration AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] 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. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
