[configuration] What about live-update of config data?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[configuration] What about live-update of config data?

Oliver Zeigermann
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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] What about live-update of config data?

Oliver Heger
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] What about live-update of config data?

Oliver Zeigermann
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.

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.

Oliver

On 6/14/05, Oliver Heger <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] What about live-update of config data?

Oliver Heger
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 <[hidden email]> 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: [hidden email]
>>For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] What about live-update of config data?

Oliver Zeigermann
In reply to this post by Oliver Zeigermann
On the other hand

http://www.cenqua.com/clover/eg/jboss/report/org/jboss/util/TimedCachePolicy.html

e.g. the JBoss people do not seem to care about not using
java.util.Timer themselves ;)

Oliver

On 6/14/05, Oliver Zeigermann <[hidden email]> 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.
>
> 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.
>
> Oliver
>
> On 6/14/05, Oliver Heger <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] What about live-update of config data?

Oliver Zeigermann
In reply to this post by Oliver Heger
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> >>For additional commands, e-mail: [hidden email]
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] What about live-update of config data?

Oliver Zeigermann
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> > >>For additional commands, e-mail: [hidden email]
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] What about live-update of config data?

Oliver Heger
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>>>>>For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: [hidden email]
>>>For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] What about live-update of config data?

Oliver Zeigermann
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> >>>>>For additional commands, e-mail: [hidden email]
> >>>>>
> >>>>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: [hidden email]
> >>>For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] What about live-update of config data?

Emmanuel Bourg-3
In reply to this post by Oliver Zeigermann
Oliver Zeigermann wrote:
> On the other hand
>
> http://www.cenqua.com/clover/eg/jboss/report/org/jboss/util/TimedCachePolicy.html
>
> e.g. the JBoss people do not seem to care about not using
> java.util.Timer themselves ;)

Yes, we can provide a Timer based and an event based strategy, and let
the user pick the one that suits its needs. I see nothing wrong in using
a background thread in a simple web application for example, as long as
the thread is properly stopped when the application is undeployed or
stopped.

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] What about live-update of config data?

Oliver Zeigermann
In reply to this post by Oliver Heger
OK, I prepared a very rudimentary sketch as a basis for discussion:

http://issues.apache.org/bugzilla/show_bug.cgi?id=35433

Any comments?

Oliver

On 6/14/05, Oliver Heger <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> >>>>>For additional commands, e-mail: [hidden email]
> >>>>>
> >>>>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: [hidden email]
> >>>For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration] What about live-update of config data?

Oliver Heger-2
Thank you, Oliver, this is a good starting point.

Some points, which come in my mind:

- In addition to this registry mechanism we should also provide a
generic event listener mechanism, and I think the two should be very
similar, i.e. using the same listener interfaces and semantics. So it
would be worth polishing the interfaces a bit. We could define a generic
ConfigurationEvent class which stores the affected property, maybe its
old and new values and an event type. For the listener interface we
could add different callback methods, e.g. for a newly added property,
for a changed property, for a removed property etc.

- Is there a specific reason why BasicConfigRegistry holds a reference
to a TickProvider? I think it is only used in the constructor for
registration. Maybe it is better to decouple these classes.

- It would make sense to trigger the registry not only by a
TickProvider, but also support the event listener mechanism (when it is
implemented). The registry would then itself be an event listener and
registeres at configurations to be monitored. Then a user could choose
between an event based or a timer based change notification.

- I am not quite sure, but there may be some points which might cause
problems for a concrete implementation. One point is that a property can
have multiple values, which can be stored as lists or arrays. This must
be taken into account when detecting changes. For the implementation of
a generic event listener mechanism there is the problem that many
methods that have to trigger events call other methods which also
trigger events. An example is the setProperty() method that is
implemented by calling clearProperty() and then addProperty(). So for a
set operation two events would be fired. Another example is the clear()
method, which erases a configuration by calling clearProperty() on each
defined property. Here we should exactly define which events we want to
fire and which should be avoided.

Oliver

Oliver Zeigermann wrote:

>OK, I prepared a very rudimentary sketch as a basis for discussion:
>
>http://issues.apache.org/bugzilla/show_bug.cgi?id=35433
>
>Any comments?
>
>Oliver
>
>  
>
<snip>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]