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:35:00 GMT
Any idea how the source of the ticks might look like apart from
java.util.Timer or what is being worked on in
http://www.jcp.org/en/jsr/detail?id=236?

Oliver

On 6/14/05, Oliver Zeigermann <oliver.zeigermann@gmail.com> wrote:
> 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