commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Heger (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CONFIGURATION-520) Rework reloading mechanisms
Date Sat, 24 May 2014 13:44:01 GMT

     [ 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)

Mime
View raw message