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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > >>>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>>> > >>>>> > >>> > >>>--------------------------------------------------------------------- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
