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]
