Hi,
in the last few days I have worked on a new approach for handling
reloading in a more generic and loosely coupled way. To get a better
base for discussion, I created some code (mainly in the reloading and
the new builder packages).
The basic idea is that reloading is no more handled by the Configuration
object, but by a ConfigurationBuilder. Fully initialized configurations
can be obtained from corresponding builder objects.
A new class ReloadingController is responsible for reload operations. It
has a ReloadingDetector for monitoring a specific configuration source.
When a change is detected it just fires an event. The controller has a
method for triggering the check for changes. It has to be called by an
external component whenever a check is to be done. This could be done
for instance by a timer task.
A special reloading builder (ReloadingFileBasedConfigurationBuilder) is
associated with such a controller and receives change notifications. On
receiving an event it is reset so that on next access a new
configuration has to be created.
So when following this approach, for applications a reference to the
builder is more important than a Configuration object. When
configuration data is needed, the Configuration is obtained from the
builder and accessed; this instance will not be changed by a reload
operation. In [1] I have already described the pros and cons of this
approach as I see them.
Feedback is welcome!
Oliver
[1] http://www.mail-archive.com/dev@commons.apache.org/msg33669.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
