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]
