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 14:29:53 GMT
Yes, the timer service is the one in JCP 236. You are right, just a
tick to check at the registry togther with some configurable providers
for the tick. Possbile implementations may include one for
- javax.management.timer.Timer
- java.util.Timer
- JMX

Agreed?

Oliver

On 6/14/05, Oliver Heger <hegero@med.uni-marburg.de> wrote:
> Nothing too concrete yet. Depending on an application's needs there are
> multiple possibilites one can think of. It may even not be necessary to
> check the configuration at regular intervals, but an admin could
> manually force a reload e.g. by invoking a JMX method.
> 
> JMX could be an option for a timer service, too. Another option would be
> a scheduler like quarzt. In J2EE 1.4 there is an EJB timer service. Is
> this the same as the one you refered to (JCP 236)?
> 
> Oliver
> 
> Oliver Zeigermann wrote:
> > 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
> >
> >
> 
> ---------------------------------------------------------------------
> 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