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
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

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

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.

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

Fully agreed. Concerning a triggered thing, what would be the source
for such a trigger.

Considering this

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.

6/14/05, Heger <hegero (AT) med (DOT) uni-marburg.dewrote:
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

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.

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

Zeigermann wrote:
Fully agreed. Concerning a triggered thing, what would be the source
for such a trigger.

Considering this

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).

6/14/05, Heger <hegero (AT) med (DOT) uni-marburg.dewrote:

>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


>>
>>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.
>>
>>
>>
>>
>>To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
>>For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>>
>>

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

the other hand

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

6/14/05, Zeigermann <oliver.zeigermann (AT) gmail (DOT) comwrote:
Fully agreed. Concerning a triggered thing, what would be the source
for such a trigger.

Considering this

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.

6/14/05, Heger <hegero (AT) med (DOT) uni-marburg.dewrote:
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

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

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>
>
>

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

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

6/14/05, Heger <hegero (AT) med (DOT) uni-marburg.dewrote:
Zeigermann wrote:
Fully agreed. Concerning a triggered thing, what would be the source
for such a trigger.

Considering this

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).

6/14/05, Heger <hegero (AT) med (DOT) uni-marburg.dewrote:
>
>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


>>
>>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.
>>
>>
>>
>>
>>To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
>>For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>>
>>

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

Any idea how the source of the ticks might look like apart from
java.util.Timer or what is being worked on in

6/14/05, Zeigermann <oliver.zeigermann (AT) gmail (DOT) comwrote:
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

6/14/05, Heger <hegero (AT) med (DOT) uni-marburg.dewrote:
Zeigermann wrote:
Fully agreed. Concerning a triggered thing, what would be the source
for such a trigger.

Considering this

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).

--

6/14/05, Heger <hegero (AT) med (DOT) uni-marburg.dewrote:
>
>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


>>
>>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.
>>
>>
>>
>>
>>To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
>>For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>>
>>
>

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>
>
>

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

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)?

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

6/14/05, Zeigermann <oliver.zeigermann (AT) gmail (DOT) comwrote:

>>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
>>
>>
>>
>6/14/05, Heger <hegero (AT) med (DOT) uni-marburg.dewrote:
>>
Zeigermann wrote:

Fully agreed. Concerning a triggered thing, what would be the source
for such a trigger.

Considering this

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).

6/14/05, Heger <hegero (AT) med (DOT) uni-marburg.dewrote:

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

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.

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org


>>

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

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?

6/14/05, Heger <hegero (AT) med (DOT) uni-marburg.dewrote:
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)?

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

6/14/05, Zeigermann <oliver.zeigermann (AT) gmail (DOT) comwrote:
>
>>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
>>
>>
>>
>6/14/05, Heger <hegero (AT) med (DOT) uni-marburg.dewrote:
>>
Zeigermann wrote:

Fully agreed. Concerning a triggered thing, what would be the source
for such a trigger.

Considering this

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).

6/14/05, Heger <hegero (AT) med (DOT) uni-marburg.dewrote:

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

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.

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org


>>
>

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
--

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

Zeigermann wrote:
the other hand

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: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

K, I prepared a very rudimentary sketch as a basis for discussion:

Any comments?

6/14/05, Heger <hegero (AT) med (DOT) uni-marburg.dewrote:
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)?

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

6/14/05, Zeigermann <oliver.zeigermann (AT) gmail (DOT) comwrote:
>
>>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
>>
>>
>>
>6/14/05, Heger <hegero (AT) med (DOT) uni-marburg.dewrote:
>>
Zeigermann wrote:

Fully agreed. Concerning a triggered thing, what would be the source
for such a trigger.

Considering this

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).

6/14/05, Heger <hegero (AT) med (DOT) uni-marburg.dewrote:

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

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.

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org


>>
>

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
--

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

Thank you, , 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. 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.

Zeigermann wrote:

>K, I prepared a very rudimentary sketch as a basis for discussion:
>
>
>
>Any comments?
>
>
>

<snip>

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org