[
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
