Details
-
Improvement
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
None
-
None
-
37324
Description
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.
Attachments
Issue Links
- relates to
-
-
- Closed
-