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
- 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.