commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Hufgard <>
Subject Re[2]: [Configuration] PropertiesConfiguration ReloadStrategy not working as expected
Date Fri, 20 May 2005 20:13:49 GMT
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

> 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

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


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

View raw message