commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Zeigermann <oliver.zeigerm...@gmail.com>
Subject Re: [configuration] What about live-update of config data?
Date Tue, 14 Jun 2005 12:00:41 GMT
Thanks for the interesting information. I still think this might be a
valuable addition. If I find some time soon I will implement something
for further consideration.

Cheers

Oliver

On 6/14/05, Oliver Heger <hegero@med.uni-marburg.de> wrote:
> Oliver Zeigermann wrote:
> > Fully agreed. Concerning a triggered thing, what would be the source
> > for such a trigger.
> >
> > Considering this
> >
> > http://www.jcp.org/en/jsr/detail?id=236
> >
> > 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
> extension?).
> 
> >
> > 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
> 
> >
> > Oliver
> >
> > On 6/14/05, Oliver Heger <hegero@med.uni-marburg.de> wrote:
> >
> >>Oliver Zeigermann wrote:
> >>
> >>>Folks,
> >>>
> >>>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
> >>>
> >>>Oliver
> >>>
> >>
> >>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
> >>detected.
> >>
> >>In short, I would like to see features like that in future releases of
> >>commons-configuration.
> >>
> >>Oliver
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
>

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


Mime
View raw message