[
https://issues.apache.org/jira/browse/CONFIGURATION-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-520.
----------------------------------------
Resolution: Fixed
This has been implemented and also documented in the user's guide.
> 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 was sent by Atlassian JIRA
(v6.2#6252)
