commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorge Ferrer <>
Subject Re: Re[2]: [Configuration] PropertiesConfiguration ReloadStrategy not working as expected
Date Sun, 22 May 2005 08:38:36 GMT
Hi Christian,

Oliver has attached a patch to Bugzilla which solves the problem. OTH,
I've added a class which can be used for version 1.1 as a substitute
of FileChangedReloadingStrategy meanwhile a new release is made .

Related to listeners, could you share your code and some examples of
how it is used? I find it very interesting but I'm still confused
about some details.


On 5/20/05, Christian Hufgard <> wrote:
> Hello Oliver,
> think I should have taken a look into bugzilla before mailing...
> > Certainly not. There are some problems related to locating files and the
> > reloading mechanism. You might want to check out the bug reports in
> > bugzilla (just enter [configuration] as search expression). A few issues
> > have already been fixed, so you could give the latest nightly builds a try.
> Found bug# 34289 dealing with this issue. For myself, I fixed this
> with setting the basepath to the PropertiesConfiguration after having
> constructed the object. This way I did not had to change any code in
> any configuration class.
> > Observable configurations in the first line meant that you can register
> > some listener at a configuration that will be notified about changes at
> > its properties.
> > ...
> > IIUYC you register your listeners at the reloading strategy.
> Thats exactly the way I implemented it. I have a Vector of Listeners
> that get informed as soon, as a update is performed. For that I
> overwrote the FileChangedReloadingStrategy's reloadingPerformed
> method.
> > So events will be fired e.g. when setProperty() or
> > clearProperty() will be called on this configuration.
> Ok, think I would miss these events. But for me this is no problem,
> since the Properties are only modified in properties files.
> > I think this is very interesting. But if you want the reloading strategy
> > perform periodic checks, doesn't this enforce the construction of a
> > thread? This could be quite problematic in some environments (J2EE).
> Depends... As far as I remember, in a JMX-Bean you are allowed to
> spawn Threads. So you could create a JMX based watchdog and a POJO
> watchdog.
> >>The other is the possibility to use the ConfigurationFactory in combination
> >>with a ReloadingStrategy.
> > For ConfigurationFactory a major refactoring is planned. This would be a
> > good opportunity to add such a feature. In the long term I would like to
> > have a more general reloading mechanism. ATM only file based
> > configurations are supported. But I am not sure yet how this could look
> > like.
> Think this is bug# 34350. For most other sources that files it would
> be some more difficult to track down changes without reloading the
> whole data or defining an identifier that indicates the time the
> properties were changed at. This would make it a kind of unintuitiv to
> change e.g. JNDI-properties.
> Thank you for pointing me out to bugzilla :)
> Christian
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Un abrazo,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message