Uploaded image for project: 'Commons Configuration'
  1. Commons Configuration

FileReloadingStrategy should run in a background thread



    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0
    • Component/s: File reloading
    • Labels:
    • Bugzilla Id:


      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.


          Issue Links



              • Assignee:
                mech@tngtech.com Michael Echerer
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: