[jira] [Created] (CONFIGURATION-520) Rework reloading mechanisms

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Created] (CONFIGURATION-520) Rework reloading mechanisms

ASF GitHub Bot (Jira)
Oliver Heger created CONFIGURATION-520:
------------------------------------------

             Summary: Rework reloading mechanisms
                 Key: CONFIGURATION-520
                 URL: https://issues.apache.org/jira/browse/CONFIGURATION-520
             Project: Commons Configuration
          Issue Type: Improvement
          Components: File reloading
    Affects Versions: 1.9
            Reporter: Oliver Heger
             Fix For: 2.0


The current implementation of reloading features is tightly coupled to file-based configurations: On each property access a reloading strategy is queried; if it indicates that a reload is required, the content of the configuration is replaced by the file on hard disc.

The advantage of this approach is that it is very transparent for client code; no specific actions have to be taken to enable reloading. However, there are also many problems:
* There is no control over reloading. It can happen at any time. This could cause problems if a configuration contains multiple related properties, and a reload happens while an application reads them: properties read before the reload may not be compatible with values read afterwards.
* There is no sound error handling. A failed reload operation corrupts the configuration (see CONFIGURATION-136).
* There is no support for other reloading triggers (e.g. periodic checks) or event notifications when the change of a configuration source is detected.
* The implementation of reloading features is spread over a bunch of methods in {{AbstractFileConfiguration}}; each affected method contains a reload check.
* It is very hard (or even impossible) to provide an efficient thread-safe implementation of configurations; there has to be synchronization with reloading operations.
* The mechanisms available are specific to file-based configurations, there is no generic approach.

The disadvantages listed above can be addressed by moving reloading functionality from specific {{Configuration}} implementations to builder objects responsible for the creation of configurations (see CONFIGURATION-519). This would require client code to deal with reloading in a slightly different (and probably slightly less transparent) way, but it would simplify the current implementation and enable advanced reloading features.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira