Oliver Heger updated CONFIGURATION-202:
Fix Version/s: (was: 1.7)
> 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.8
> 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.