[Configuration] PropertiesConfiguration ReloadStrategy not working as expected

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[Configuration] PropertiesConfiguration ReloadStrategy not working as expected

Christian Hufgard
Hi everyone!

Since yesterday I am a user of Configuration (1.1) - waited a long time for
the release to replace the stuff I wrote for myself. I tried to replace my
own properties handler with the one provided by Configuration.
To to this, I created a PropertiesConfiguration the following way:

PropertiesConfiguration propsConfig =
   new PropertiesConfiguration(propertiesFileName);
reloading = new FileChangedReloadingStrategy();
                                       
propsConfig.setReloadingStrategy(reloading);

propertiesFileName is the name of a properties-file that can be found in the
shared/classes directory of my tomcat. Loading the properties from there
worked fine. But the reloading did not work.
So I took a look into the code and found out, that the
FileChangedReloadingStrategy does not observe the right file. It was looking
just for the filename without any basepath.

When I instantiate the ReloadingStrategy with a complete path it works the
way it should. Is this behaviour intended?



Also I would like to diskuss some features, which I am misssing.

First is the possibility to inform classes about a change at the properties,
which I need for at leat one class, that has some cron-like job. I wrote a
subclass of FileChangedReloadingStrategy that informs Listeners about
changes at the properties. Would something like this be usefull for someone
else?
Think a periodically checking of the properties the way log4j does it, would
also be nice to retrieve information independent to a user interacting with
the system.

Is this planned for Version 1.3? Task: observable configurations?


The other is the possibility to use the ConfigurationFactory in combination
with a ReloadingStrategy. I want to read the configuration details from a
xml file with

ConfigurationFactory factory = new ConfigurationFactory("config.xml");
Configuration config = factory.getConfiguration();

to have a flexibel way to change it, but do not want to loose the chance to
get informed if the config changes. Is a feature like this planned for
future releases?

Greets

Christian

--
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse f?r Mail, Message, More +++

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Configuration] PropertiesConfiguration ReloadStrategy not working as expected

Oliver Heger-2
Hi Christian,

Christian Hufgard wrote:

>Hi everyone!
>
>Since yesterday I am a user of Configuration (1.1) - waited a long time for
>the release to replace the stuff I wrote for myself. I tried to replace my
>own properties handler with the one provided by Configuration.
>To to this, I created a PropertiesConfiguration the following way:
>
>PropertiesConfiguration propsConfig =
>   new PropertiesConfiguration(propertiesFileName);
>reloading = new FileChangedReloadingStrategy();
>
>propsConfig.setReloadingStrategy(reloading);
>
>propertiesFileName is the name of a properties-file that can be found in the
>shared/classes directory of my tomcat. Loading the properties from there
>worked fine. But the reloading did not work.
>So I took a look into the code and found out, that the
>FileChangedReloadingStrategy does not observe the right file. It was looking
>just for the filename without any basepath.
>
>When I instantiate the ReloadingStrategy with a complete path it works the
>way it should. Is this behaviour intended?
>  
>
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.

>Also I would like to diskuss some features, which I am misssing.
>
>First is the possibility to inform classes about a change at the properties,
>which I need for at leat one class, that has some cron-like job. I wrote a
>subclass of FileChangedReloadingStrategy that informs Listeners about
>changes at the properties. Would something like this be usefull for someone
>else?
>Think a periodically checking of the properties the way log4j does it, would
>also be nice to retrieve information independent to a user interacting with
>the system.
>
>Is this planned for Version 1.3? Task: observable configurations?
>  
>
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. So events will be fired e.g. when setProperty() or
clearProperty() will be called on this configuration. IIUYC you register
your listeners at the reloading strategy.

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

>
>The other is the possibility to use the ConfigurationFactory in combination
>with a ReloadingStrategy. I want to read the configuration details from a
>xml file with
>
>ConfigurationFactory factory = new ConfigurationFactory("config.xml");
>Configuration config = factory.getConfiguration();
>
>to have a flexibel way to change it, but do not want to loose the chance to
>get informed if the config changes. Is a feature like this planned for
>future releases?
>  
>
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.

>Greets
>
>Christian
>
Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Christian Hufgard
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

jferrer
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Un abrazo,
    Jorge

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]