Am 11.10.2012 22:22, schrieb Honton, Charles:
So the Configuration is immutable and consistent.

Currently, the Configuration interface allows manipulating property values. So there still has to be synchronization for readers and writers. An immutable configuration interface has already been discussed and would certainly make a good addition.

With the existing reloading implementation there is the problem that it is very tightly integrated into configuration implementations. All access methods have to check whether reloading is required. This also means that a Configuration object can change its content at any time. It is very hard to get this correctly synchronized in an efficient way.


Can the Builder clients listen for change events?

Clients can register listeners for property changes at a configuration and for resets of the builder. Listeners of the latter kind are notified when a reload is required, so they can request a new Configuration object.


Is there a separate interface to the Builder to change the configuration
state and fire persist events?

The builder stores the location from which the Configuration was loaded. This can be used to persist changes. However, there is not yet a persist event. Could you give a use case for such a notification?

Thank you for the feedback!
Oliver


Thanks,
chas

On 10/11/12 1:09 PM, "Oliver Heger" <oliver.he...@oliver-heger.de> wrote:

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



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to