[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