commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <heg...@med.uni-marburg.de>
Subject Re: [configuration] What about live-update of config data?
Date Tue, 14 Jun 2005 13:11:53 GMT
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


Mime
View raw message