You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Oliver Heger <ol...@oliver-heger.de> on 2012/10/11 22:09:53 UTC
[configuration] POC new reloading approach
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] POC new reloading approach
Posted by Oliver Heger <ol...@oliver-heger.de>.
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" <ol...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [configuration] POC new reloading approach
Posted by "Honton, Charles" <Ch...@intuit.com>.
So the Configuration is immutable and consistent.
Can the Builder clients listen for change events?
Is there a separate interface to the Builder to change the configuration
state and fire persist events?
Thanks,
chas
On 10/11/12 1:09 PM, "Oliver Heger" <ol...@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-unsubscribe@commons.apache.org
>For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org