[jira] Updated: (CONFIGURATION-202) FileReloadingStrategy should run in a background thread

["Emmanuel Bourg (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CONFIGURATION-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emmanuel Bourg updated CONFIGURATION-202:
-----------------------------------------

    Environment:     (was: Operating System: other
Platform: Other)
        Summary: FileReloadingStrategy should run in a background thread  (was: [configuration] FileReloadingStrategy should run in a background thread)

> 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
>            Reporter: Michael Echerer
>            Priority: Minor
>             Fix For: 1.5
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org