commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] What about live-update of config data?
Date Tue, 14 Jun 2005 11:55:13 GMT
Oliver Zeigermann wrote:
> Fully agreed. Concerning a triggered thing, what would be the source
> for such a trigger.
> Considering this
> java.util.Timer might cause problems in a J2EE environment and there
> is no Timer for Application Servers, yet.

Right, this is a problem and that's the reason why I very unspecifically 
wrote "by some external sources" ;-)

My idea was to approach this in a very abstract way. A reloading 
strategy would define a tick() method, which would cause it to check its 
source file. Then it would be left to a concrete application to ensure 
that this method gets called periodically. E.g. for non managed 
environments a simple timer based service could be provided. In an 
AppSvr a different approach must be used (e.g. a servlet filter that 
triggers the reloading strategy at each request? or a server specific 

> By the way how is the reloading facility triggered right now? Is it
> triggered at all or is it checked upon every access to the config.

It is indeed checked for each access (which causes a very tight coupling 
between a configuration and its reloading strategy).


> Oliver
> On 6/14/05, Oliver Heger <> wrote:
>>Oliver Zeigermann wrote:
>>>I was wondering if there is something like a live update for classes
>>>depending on configuration data that might change while the
>>>application is running?
>>>I was thinking of something like a registry mechanism where an object
>>>tells a central service that it depends on this and that property and
>>>gets a call back as soon as the property changes.
>>>Is there something like that in the configuration component? If not,
>>>would it be an option to include it in future releases?
>>>Thanks in advance and cheers
>>What we have thought about are observable configurations, i.e. you
>>register an event listener at a configuration and get then notified
>>about changes at properties. But there is nothing concrete yet.
>>Your suggestion goes a bit further by allowing a listener to exactly
>>specify in which events it is interested. I think this is a good idea
>>because typically not all portions of a configuration are important
>>enough to react on every change. If we had a generic event notification
>>mechanism, your registry could be implemented on top of that.
>>A similar point I had in mind is a combination of such an event
>>notification mechanism and our reloading facilities. If a reloading
>>strategy could be triggered (by some external sources) to periodically
>>check configuration files, it could send events whenever a change is
>>In short, I would like to see features like that in future releases of
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message