Re[2]: [Configuration] PropertiesConfiguration ReloadStrategy not working as expected

[Christian Hufgard <ch...@gmx.de>]

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: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: Re[2]: [Configuration] PropertiesConfiguration ReloadStrategy not working as expected

[Jorge Ferrer <jo...@gmail.com>]

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.

Regards,
Jorge

On 5/20/05, Christian Hufgard <ch...@gmx.de> 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: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
> 


-- 
Un abrazo,
    Jorge

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org