You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Emmanuel Bourg <e....@cross-systems.com> on 2003/12/11 17:26:36 UTC
[configuration] Automatic reloading
Greetings, I'd like to contribute a slight modification to reload
automatically a PropertiesConfiguration if the underlying .properties
file has been changed. I had to implement this to prevent restarting my
web application every time a configuration file is modified.
The auto reload mode is enabled by calling setAutoReload(true) on the
PropertiesConfiguration instance. It's disabled by default. Every time a
property is accessed with getXXX(key) the date of the file is checked
and the configuration is reloaded if the previous date known is older.
This check is executed only once every 5 seconds to prevent hammering
the file system.
I'm attaching the patch and the modified files to this mail, all test
cases passed successfully. I've also added a specific test case for the
automatic reloading scenario.
Emmanuel Bourg
Re: [configuration] Automatic reloading
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Emmanuel Bourg <e....@cross-systems.com>:
> Greetings, I'd like to contribute a slight modification to reload
> automatically a PropertiesConfiguration if the underlying .properties
> file has been changed. I had to implement this to prevent restarting my
> web application every time a configuration file is modified.
>
> The auto reload mode is enabled by calling setAutoReload(true) on the
> PropertiesConfiguration instance. It's disabled by default. Every time a
> property is accessed with getXXX(key) the date of the file is checked
> and the configuration is reloaded if the previous date known is older.
> This check is executed only once every 5 seconds to prevent hammering
> the file system.
>
> I'm attaching the patch and the modified files to this mail, all test
> cases passed successfully. I've also added a specific test case for the
> automatic reloading scenario.
>
> Emmanuel Bourg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] Automatic reloading
Posted by Eric Galluzzo <eg...@einnovation.com>.
Emmanuel Bourg wrote:
> I like the idea of a decorator, I'm implementing it currently. I see
> one issue though, I was considering a refactoring of the include logic
> in BasePropertiesConfiguration to use a tree of configurations, i.e.
> if the property can't be found in the parent configuration, it would
> look up in the children configurations.
>
> With a decorator pattern the included configurations can't be reloaded
> automatically unless the BasePropertiesConfiguration wraps them in a
> ReloadableConfiguration. In this case it wouldn't be possible to
> manage their reloading properties (enabling/disabling, refresh delay).
> If the PropertiesConfiguration was reloadable, it could propagate its
> reloading properties to its children.
Actually, you could still support that. Just have FileConfiguration
have a File[] getFiles() method (or Iterator getFileIterator() ) method
instead of a getFile() method. Then you could do this:
public class BasePropertiesConfiguration extends ... implements
FileConfiguration
{
protected File fPropertiesFile;
protected List fChildList = new ArrayList( 2 );
...
public File[] getFiles()
{
List allFiles = new ArrayList();
allFiles.add( fPropertiesFile );
for ( Iterator iter = fChildList.iterator(); iter.hasNext(); )
{
FileConfiguration child = (FileConfiguration) iter.next();
allFiles.addAll( Arrays.asList( child.getFiles() ) );
}
File[] fileArray = new File[allFiles.size()];
return (File[]) allFiles.toArray( fileArray );
}
...
}
I've not actually looked at the BasePropertiesConfiguration code, but
that's a rough approximation of what you could do. Then
ReloadableConfiguration could check all the files returned by getFiles()
and reload the base configuration (which would reload the children) if
any of the files had changed. Or you could do something fancier,
traversing to the individual child Configurations using some sort of
CompositeConfiguration and only reloading the individual Configuration
that changed; but that would probably be more trouble than it would be
worth.
- Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] Automatic reloading
Posted by Emmanuel Bourg <e....@cross-systems.com>.
I like the idea of a decorator, I'm implementing it currently. I see one
issue though, I was considering a refactoring of the include logic in
BasePropertiesConfiguration to use a tree of configurations, i.e. if the
property can't be found in the parent configuration, it would look up in
the children configurations.
With a decorator pattern the included configurations can't be reloaded
automatically unless the BasePropertiesConfiguration wraps them in a
ReloadableConfiguration. In this case it wouldn't be possible to manage
their reloading properties (enabling/disabling, refresh delay). If the
PropertiesConfiguration was reloadable, it could propagate its reloading
properties to its children.
Emmanuel Bourg
Eric Galluzzo wrote:
> Alternatively, it might be nice to introduce a FileConfiguration
> interface that just has a java.io.File getFile() method. Both
> DOM4JConfiguration and PropertiesConfiguration would implement this.
> Then one could repackage your existing ReloadablePropertiesConfiguration
> as a ReloadableConfiguration that implements Configuration but delegates
> to another FileConfiguration and checks the file every so often. Thus:
>
> Configuration config = new ReloadableConfiguration(
> new DOM4JConfiguration( myXMLFile ) );
>
> or
>
> Configuration config = new ReloadableConfiguration(
> new PropertiesConfiguration( myPropFile ) );
>
> This is a Decorator design reminiscent of FilteredOutputStream and
> FilteredInputStream.
>
> - Eric
>
[configuration] Exception handling - was Automatic reloading
Posted by Oliver Heger <he...@med.uni-marburg.de>.
Emmanuel,
;-) thank you for putting my name in the author field of
ReloadingStrategy, but I do not deserve this honour. This is all your
design.
I have one remark and this is not specific to your code, but applies to
whole configuration: Our exception handling is very inconsistent in some
points. For instance, in the new PersistentConfiguration interface the
save() method throws an IOException and the load() method throws an
Exception. I know, this is because the underlying methods you want to
call have these throws clauses. So I would suggest to make this more
consistent.
There are some methods that have a throws Exception clause, which is
quite ugly in my opinion. Well, some of them can indeed throw a bunch of
different exception types. What could we do to improve this? How about
introducing a ConfigurationException class, which can have a nested
exception?
What do others think about this? This is a kind of cleanup, which maybe
should be done before the first release. Later it could be more
problematic because of compatibility issues.
Oli
Emmanuel Bourg schrieb:
> I have implemented the reloading strategy suggested by Oliver. I
> introduced a PersistentConfiguration interface defining the load() and
> save() methods, the ReloadableConfiguration decorator only accepts
> instances of PersistenConfiguration. Also I fixed the missing clear()
> method in the HierarchicalConfiguration class and moved the reloading
> stuff in a specific sub package.
>
> I haven't implemented all the strategies mentioned in my previous mail
> yet. I think we might make the URLChangedReloadingStrategy to work on
> configurations embedded in a jar or zip file as well, this should be
> easy to implement with the JarFile/JarEntry obtained from the URL
> through a JarURLConnection.
>
> Emmanuel Bourg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] Automatic reloading
Posted by Emmanuel Bourg <e....@cross-systems.com>.
I have implemented the reloading strategy suggested by Oliver. I
introduced a PersistentConfiguration interface defining the load() and
save() methods, the ReloadableConfiguration decorator only accepts
instances of PersistenConfiguration. Also I fixed the missing clear()
method in the HierarchicalConfiguration class and moved the reloading
stuff in a specific sub package.
I haven't implemented all the strategies mentioned in my previous mail
yet. I think we might make the URLChangedReloadingStrategy to work on
configurations embedded in a jar or zip file as well, this should be
easy to implement with the JarFile/JarEntry obtained from the URL
through a JarURLConnection.
Emmanuel Bourg
Re: [configuration] Automatic reloading
Posted by Oliver Heger <Ol...@t-online.de>.
Emmanuel Bourg wrote:
> Oliver Heger wrote:
>
>> Emmanuel,
>>
>> I think after you changed the Configuration interface some classes
>> won't compile any more because they also implement this interface.
>> Did you check that?
>
>
> You are right that breaks the HierarchicalConfiguration subclasses, I
> forgot to add the clear() implementation there. The classes based on
> BaseConfiguration (xml, jndi & properties) are safe.
Right, I had something in mind that CompositeConfiguration would also be
affected, but this class already has a clear() method.
>
>
>> I like the idea with reloading properties, but the actual
>> implementation seems to be a bit too specific for my taste. It is now
>> possible to reload properties read from file. Some weeks ago the
>> configuration classes have been extended to support loading from a
>> URL. Here a reload can't be performed at the moment. And Tim's
>> suggestion to specify a refresh delay in the configuration definition
>> XML file is not supported either.
>
>
> For configurations loaded from an URL we might force the reloading
> after an expiration time, for example 15 minutes. This time could be
> changed like the refresh delay.
>
>
>> I admit that reloading file based properties will be needed most
>> times, so this is a good beginning. But maybe we can find a more
>> generic approach that also supports the other use cases?
>>
>> Perhaps we can introduce something like a Trigger interface (or a
>> similar concept). Such a trigger can be passed to the Reload
>> decorator. Then the decorator won't be limited to file change events.
>> Just an idea...
>
>
> Using an interchangeable strategy is an interesting idea. We could
> define an abstract class or an interface ReloadingStrategy like this :
>
> public interface ReloadingStrategy {
> void setConfiguration(Configuration configuration);
> boolean reloadingRequired();
> void reloadingPerformed();
> }
>
> I would consider the following implementations :
>
> InvariantReloadingStrategy (no reloading performed)
> TimeoutReloadingStrategy (reload after n seconds)
> FileChangedReloadingStrategy (reload when the file is changed)
> URLChangedReloadingStrategy (for http based URLs only)
> CompositeReloadingStrategy (to mix several strategies)
+1
I am a bit afraid that the actual implementations of
ConfigurationFactory and CompositeConfiguration may cause trouble when
implementing this feature. At least when you have a union configuration,
all properties are collected in a single HierarchicalConfiguration
object, so the information where they have been loaded from is lost.
Should always the whole union configuration be loaded when something
changes? I am not sure how to handle this best...
>
> Emmanuel Bourg
>
>
>
>
>
Oli
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] Automatic reloading
Posted by Emmanuel Bourg <e....@cross-systems.com>.
Oliver Heger wrote:
> Emmanuel,
>
> I think after you changed the Configuration interface some classes won't
> compile any more because they also implement this interface. Did you
> check that?
You are right that breaks the HierarchicalConfiguration subclasses, I
forgot to add the clear() implementation there. The classes based on
BaseConfiguration (xml, jndi & properties) are safe.
> I like the idea with reloading properties, but the actual implementation
> seems to be a bit too specific for my taste. It is now possible to
> reload properties read from file. Some weeks ago the configuration
> classes have been extended to support loading from a URL. Here a reload
> can't be performed at the moment. And Tim's suggestion to specify a
> refresh delay in the configuration definition XML file is not supported
> either.
For configurations loaded from an URL we might force the reloading after
an expiration time, for example 15 minutes. This time could be changed
like the refresh delay.
> I admit that reloading file based properties will be needed most times,
> so this is a good beginning. But maybe we can find a more generic
> approach that also supports the other use cases?
>
> Perhaps we can introduce something like a Trigger interface (or a
> similar concept). Such a trigger can be passed to the Reload decorator.
> Then the decorator won't be limited to file change events. Just an idea...
Using an interchangeable strategy is an interesting idea. We could
define an abstract class or an interface ReloadingStrategy like this :
public interface ReloadingStrategy {
void setConfiguration(Configuration configuration);
boolean reloadingRequired();
void reloadingPerformed();
}
I would consider the following implementations :
InvariantReloadingStrategy (no reloading performed)
TimeoutReloadingStrategy (reload after n seconds)
FileChangedReloadingStrategy (reload when the file is changed)
URLChangedReloadingStrategy (for http based URLs only)
CompositeReloadingStrategy (to mix several strategies)
Emmanuel Bourg
Re: [configuration] Documentation Patch
Posted by Oliver Heger <he...@med.uni-marburg.de>.
Yes, the patch is fine. Unfortunately I cannot apply it because I have
no commit rights, so we will have to wait until a commiter has some time.
But I think it should be applied as soon as possible to avoid new users
being confused.
Oli
Tim Reilly schrieb:
> RE: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25459
>
> Was the patch I sent ok?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [configuration] Documentation Patch
Posted by Tim Reilly <ti...@consultant.com>.
RE: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25459
Was the patch I sent ok?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] Automatic reloading
Posted by Oliver Heger <he...@med.uni-marburg.de>.
Emmanuel,
I think after you changed the Configuration interface some classes won't
compile any more because they also implement this interface. Did you
check that?
I like the idea with reloading properties, but the actual implementation
seems to be a bit too specific for my taste. It is now possible to
reload properties read from file. Some weeks ago the configuration
classes have been extended to support loading from a URL. Here a reload
can't be performed at the moment. And Tim's suggestion to specify a
refresh delay in the configuration definition XML file is not supported
either.
I admit that reloading file based properties will be needed most times,
so this is a good beginning. But maybe we can find a more generic
approach that also supports the other use cases?
Perhaps we can introduce something like a Trigger interface (or a
similar concept). Such a trigger can be passed to the Reload decorator.
Then the decorator won't be limited to file change events. Just an idea...
Regards
Oli
Emmanuel Bourg schrieb:
> He is an implementation of the reloadable decorator suggested by Eric. I
> have also added a set/getRefreshDelay method.
>
> Emmanuel Bourg
>
>
> Eric Galluzzo wrote:
>
>> Alternatively, it might be nice to introduce a FileConfiguration
>> interface that just has a java.io.File getFile() method. Both
>> DOM4JConfiguration and PropertiesConfiguration would implement this.
>> Then one could repackage your existing
>> ReloadablePropertiesConfiguration as a ReloadableConfiguration that
>> implements Configuration but delegates to another FileConfiguration
>> and checks the file every so often. Thus:
>>
>> Configuration config = new ReloadableConfiguration(
>> new DOM4JConfiguration( myXMLFile ) );
>>
>> or
>>
>> Configuration config = new ReloadableConfiguration(
>> new PropertiesConfiguration( myPropFile ) );
>>
>> This is a Decorator design reminiscent of FilteredOutputStream and
>> FilteredInputStream.
>>
>> - Eric
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>
> ------------------------------------------------------------------------
>
> Index: src/java/org/apache/commons/configuration/BaseConfiguration.java
> ===================================================================
> RCS file: /home/cvspublic/jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/BaseConfiguration.java,v
> retrieving revision 1.16
> diff -u -r1.16 BaseConfiguration.java
> --- src/java/org/apache/commons/configuration/BaseConfiguration.java 17 Oct 2003 08:11:52 -0000 1.16
> +++ src/java/org/apache/commons/configuration/BaseConfiguration.java 16 Dec 2003 14:33:18 -0000
> @@ -55,6 +55,7 @@
> */
>
> import java.util.Iterator;
> +import java.util.Map;
>
> import org.apache.commons.collections.SequencedHashMap;
>
> @@ -86,7 +87,7 @@
> public class BaseConfiguration extends AbstractConfiguration
> {
> /** stores the configuration key-value pairs */
> - private SequencedHashMap store = new SequencedHashMap();
> + private Map store = new SequencedHashMap();
>
> /**
> * Empty constructor. You must add all the values to this configuration.
> @@ -200,6 +201,10 @@
> }
> }
>
> + public void clear() {
> + store.clear();
> + }
> +
> /**
> * Get the list of the keys contained in the configuration
> * repository.
> @@ -208,6 +213,6 @@
> */
> public Iterator getKeys()
> {
> - return store.iterator();
> + return store.keySet().iterator();
> }
> }
> Index: src/java/org/apache/commons/configuration/Configuration.java
> ===================================================================
> RCS file: /home/cvspublic/jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/Configuration.java,v
> retrieving revision 1.6
> diff -u -r1.6 Configuration.java
> --- src/java/org/apache/commons/configuration/Configuration.java 12 Nov 2003 08:12:33 -0000 1.6
> +++ src/java/org/apache/commons/configuration/Configuration.java 16 Dec 2003 14:33:18 -0000
> @@ -131,6 +131,11 @@
> void clearProperty(String key);
>
> /**
> + * Clear all properties in the configuration.
> + */
> + void clear();
> +
> + /**
> * Gets a property from the configuration.
> *
> * @param key property to retrieve
> Index: src/java/org/apache/commons/configuration/DOM4JConfiguration.java
> ===================================================================
> RCS file: /home/cvspublic/jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/DOM4JConfiguration.java,v
> retrieving revision 1.7
> diff -u -r1.7 DOM4JConfiguration.java
> --- src/java/org/apache/commons/configuration/DOM4JConfiguration.java 11 Nov 2003 15:02:07 -0000 1.7
> +++ src/java/org/apache/commons/configuration/DOM4JConfiguration.java 16 Dec 2003 14:33:20 -0000
> @@ -87,7 +87,7 @@
> * @author <a href="mailto:dlr@apache.org">Daniel Rall</a>
> * @since 0.8.1
> */
> -public class DOM4JConfiguration extends XMLConfiguration
> +public class DOM4JConfiguration extends XMLConfiguration implements FileConfiguration
> {
> // For conformance with xpath
> private static final char ATTRIB_MARKER = '@';
> Index: src/java/org/apache/commons/configuration/PropertiesConfiguration.java
> ===================================================================
> RCS file: /home/cvspublic/jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/PropertiesConfiguration.java,v
> retrieving revision 1.12
> diff -u -r1.12 PropertiesConfiguration.java
> --- src/java/org/apache/commons/configuration/PropertiesConfiguration.java 11 Nov 2003 15:02:07 -0000 1.12
> +++ src/java/org/apache/commons/configuration/PropertiesConfiguration.java 16 Dec 2003 14:33:20 -0000
> @@ -95,7 +95,7 @@
> */
> public class PropertiesConfiguration
> extends BasePropertiesConfiguration
> - implements Configuration
> + implements FileConfiguration
> {
> /** Static logger */
> Log log = LogFactory.getLog(PropertiesConfiguration.class);
> @@ -166,6 +166,16 @@
> public void load(String fileName) throws IOException
> {
> load(getPropertyStream(fileName));
> + }
> +
> + /**
> + * Save the properties to the fileName set by setFileName
> + *
> + * @throws IOException
> + */
> + public void save() throws IOException
> + {
> + save(getFileName());
> }
>
> /**
>
>
> ------------------------------------------------------------------------
>
> package org.apache.commons.configuration;
>
> /* ====================================================================
> * The Apache Software License, Version 1.1
> *
> * Copyright (c) 1999-2003 The Apache Software Foundation. All rights
> * reserved.
> *
> * Redistribution and use in source and binary forms, with or without
> * modification, are permitted provided that the following conditions
> * are met:
> *
> * 1. Redistributions of source code must retain the above copyright
> * notice, this list of conditions and the following disclaimer.
> *
> * 2. Redistributions in binary form must reproduce the above copyright
> * notice, this list of conditions and the following disclaimer in
> * the documentation and/or other materials provided with the
> * distribution.
> *
> * 3. The end-user documentation included with the redistribution, if
> * any, must include the following acknowledgement:
> * "This product includes software developed by the
> * Apache Software Foundation (http://www.apache.org/)."
> * Alternately, this acknowledgement may appear in the software itself,
> * if and wherever such third-party acknowledgements normally appear.
> *
> * 4. The names "The Jakarta Project", "Commons", and "Apache Software
> * Foundation" must not be used to endorse or promote products derived
> * from this software without prior written permission. For written
> * permission, please contact apache@apache.org.
> *
> * 5. Products derived from this software may not be called "Apache"
> * nor may "Apache" appear in their names without prior written
> * permission of the Apache Software Foundation.
> *
> * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
> * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
> * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
> * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
> * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
> * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> * SUCH DAMAGE.
> * ====================================================================
> *
> * This software consists of voluntary contributions made by many
> * individuals on behalf of the Apache Software Foundation. For more
> * information on the Apache Software Foundation, please see
> * <http://www.apache.org/>.
> */
>
> import java.io.IOException;
>
> /**
> * A file based configuration.
> *
> * @author Emmanuel Bourg
> * @author Eric Galluzo
> * @version $Revision$, $Date$
> */
> public interface FileConfiguration extends Configuration {
>
> /**
> * Save the properties to the fileName set by setFileName.
> *
> * @throws IOException
> */
> void save() throws IOException;
>
> /**
> * Load the properties from the fileName set by setFileName
> *
> * @throws IOException
> */
> void load() throws Exception;
>
> /**
> * Return the name of the file.
> */
> String getFileName();
>
> }
>
>
> ------------------------------------------------------------------------
>
> package org.apache.commons.configuration;
>
> /* ====================================================================
> * The Apache Software License, Version 1.1
> *
> * Copyright (c) 1999-2003 The Apache Software Foundation. All rights
> * reserved.
> *
> * Redistribution and use in source and binary forms, with or without
> * modification, are permitted provided that the following conditions
> * are met:
> *
> * 1. Redistributions of source code must retain the above copyright
> * notice, this list of conditions and the following disclaimer.
> *
> * 2. Redistributions in binary form must reproduce the above copyright
> * notice, this list of conditions and the following disclaimer in
> * the documentation and/or other materials provided with the
> * distribution.
> *
> * 3. The end-user documentation included with the redistribution, if
> * any, must include the following acknowledgement:
> * "This product includes software developed by the
> * Apache Software Foundation (http://www.apache.org/)."
> * Alternately, this acknowledgement may appear in the software itself,
> * if and wherever such third-party acknowledgements normally appear.
> *
> * 4. The names "The Jakarta Project", "Commons", and "Apache Software
> * Foundation" must not be used to endorse or promote products derived
> * from this software without prior written permission. For written
> * permission, please contact apache@apache.org.
> *
> * 5. Products derived from this software may not be called "Apache"
> * nor may "Apache" appear in their names without prior written
> * permission of the Apache Software Foundation.
> *
> * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
> * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
> * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
> * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
> * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
> * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> * SUCH DAMAGE.
> * ====================================================================
> *
> * This software consists of voluntary contributions made by many
> * individuals on behalf of the Apache Software Foundation. For more
> * information on the Apache Software Foundation, please see
> * <http://www.apache.org/>.
> */
>
> import java.io.IOException;
> import java.io.File;
> import java.util.Iterator;
> import java.util.Properties;
> import java.util.Vector;
>
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
>
> /**
> * A decorator around a {@link FileConfiguration} that will reload the
> * properties everytime the configuration file is changed. The file is checked
> * every time a property is accessed. The file is not reloaded more than once
> * every 5 seconds by default, this time can be changed by setting the refresh
> * delay. The automatic reloading can be disabled by calling
> * <code>setAutoReload(false)</code>, it's enabled by default. When the file
> * is reloaded the configuration is cleared
> *
> * @author Emmanuel Bourg
> * @author Eric Galluzo
> * @version $Revision$, $Date$
> */
> public class ReloadableConfiguration implements Configuration {
>
> /** Logger */
> private Log log = LogFactory.getLog(this.getClass());
>
> private FileConfiguration configuration;
>
> /** Should the configuration be reloaded on file changes ? */
> protected boolean autoReload = true;
>
> /** The last time the configuration file was modified. */
> protected long lastModified;
>
> /** The last time the file was checked for changes. */
> protected long lastChecked;
>
> /** The minimum delay in milliseconds between checks. */
> protected long refreshDelay = 5000;
>
> /** The lock to block read access while reloading */
> private Object reloadLock = new Object();
>
> /**
> * Creates a reloadable configuration.
> *
> * @param configuration
> */
> public ReloadableConfiguration(FileConfiguration configuration) {
> this.configuration = configuration;
>
> File file = new File(configuration.getFileName());
> lastModified = file.lastModified();
> }
>
> /**
> * Tell if the auto reload mode is enabled or disabled.
> */
> public boolean isAutoReload() {
> return autoReload;
> }
>
> /**
> * Enable or disable the automatic reloading of the configuration
> * when the file is changed.
> */
> public void setAutoReload(boolean autoReload) {
> this.autoReload = autoReload;
> }
>
> public long getRefreshDelay() {
> return refreshDelay;
> }
>
> /**
> * Set the minimal time between two reloadings.
> *
> * @param refreshDelay refresh delay in milliseconds
> */
> public void setRefreshDelay(long refreshDelay) {
> this.refreshDelay = refreshDelay;
> }
>
> /**
> * Check if the configuration has changed since the last
> * time it was loaded.
> */
> protected boolean hasChanged() {
> if (configuration.getFileName() == null) {
> return false;
> }
>
> File file = new File(configuration.getFileName());
> return (file.lastModified() > lastModified);
> }
>
> /**
> * Reload the configuration if the file has been modified. The
> * configuration will not be reloaded more than once every 5 seconds.
> */
> protected void reload() {
> long now = System.currentTimeMillis();
> if (autoReload) {
> synchronized (reloadLock) {
> if ((now > lastChecked + refreshDelay) && hasChanged()) {
>
> lastChecked = now;
>
> log.debug("Reloading configuration " + configuration.getFileName());
>
> try {
> configuration.clear();
> configuration.load();
> } catch (Exception e) {
> log.warn("Unable to reload configuration", e);
> }
> }
> }
> }
> }
>
>
> public void save(String filename) throws IOException {
> configuration.save();
> lastModified = System.currentTimeMillis();
> }
>
> public Properties getProperties(String key) {
> reload();
> return configuration.getProperties(key);
> }
>
> public Object getProperty(String key) {
> reload();
> return configuration.getProperty(key);
> }
>
> public boolean getBoolean(String key) {
> reload();
> return configuration.getBoolean(key);
> }
>
> public boolean getBoolean(String key, boolean defaultValue) {
> reload();
> return configuration.getBoolean(key, defaultValue);
> }
>
> public Boolean getBoolean(String key, Boolean defaultValue) {
> reload();
> return configuration.getBoolean(key, defaultValue);
> }
>
> public byte getByte(String key) {
> reload();
> return configuration.getByte(key);
> }
>
> public byte getByte(String key, byte defaultValue) {
> reload();
> return configuration.getByte(key, defaultValue);
> }
>
> public Byte getByte(String key, Byte defaultValue) {
> reload();
> return configuration.getByte(key, defaultValue);
> }
>
> public double getDouble(String key) {
> reload();
> return configuration.getDouble(key);
> }
>
> public double getDouble(String key, double defaultValue) {
> reload();
> return configuration.getDouble(key, defaultValue);
> }
>
> public Double getDouble(String key, Double defaultValue) {
> reload();
> return configuration.getDouble(key, defaultValue);
> }
>
> public float getFloat(String key) {
> reload();
> return configuration.getFloat(key);
> }
>
> public float getFloat(String key, float defaultValue) {
> reload();
> return configuration.getFloat(key, defaultValue);
> }
>
> public Float getFloat(String key, Float defaultValue) {
> reload();
> return configuration.getFloat(key, defaultValue);
> }
>
> public int getInt(String key) {
> reload();
> return configuration.getInt(key);
> }
>
> public int getInt(String key, int defaultValue) {
> reload();
> return configuration.getInt(key, defaultValue);
> }
>
> public Integer getInteger(String key, Integer defaultValue) {
> reload();
> return configuration.getInteger(key, defaultValue);
> }
>
> public long getLong(String key) {
> reload();
> return configuration.getLong(key);
> }
>
> public long getLong(String key, long defaultValue) {
> reload();
> return configuration.getLong(key, defaultValue);
> }
>
> public Long getLong(String key, Long defaultValue) {
> reload();
> return configuration.getLong(key, defaultValue);
> }
>
> public short getShort(String key) {
> reload();
> return configuration.getShort(key);
> }
>
> public short getShort(String key, short defaultValue) {
> reload();
> return configuration.getShort(key, defaultValue);
> }
>
> public Short getShort(String key, Short defaultValue) {
> reload();
> return configuration.getShort(key, defaultValue);
> }
>
> public String getString(String key) {
> reload();
> return configuration.getString(key);
> }
>
> public String getString(String key, String defaultValue) {
> reload();
> return configuration.getString(key, defaultValue);
> }
>
> public String[] getStringArray(String key) {
> reload();
> return configuration.getStringArray(key);
> }
>
> public Vector getVector(String key) {
> reload();
> return configuration.getVector(key);
> }
>
> public Vector getVector(String key, Vector defaultValue) {
> reload();
> return configuration.getVector(key, defaultValue);
> }
>
> public Configuration subset(String prefix) {
> reload();
> return configuration.subset(prefix);
> }
>
> public Iterator getKeys() {
> reload();
> return configuration.getKeys();
> }
>
> public Iterator getKeys(String prefix) {
> reload();
> return configuration.getKeys(prefix);
> }
>
> public boolean isEmpty() {
> return configuration.isEmpty();
> }
>
> public boolean containsKey(String key) {
> return configuration.containsKey(key);
> }
>
> public void addProperty(String key, Object value) {
> configuration.addProperty(key, value);
> }
>
> public void setProperty(String key, Object value) {
> configuration.setProperty(key, value);
> }
>
> public void clearProperty(String key) {
> configuration.clearProperty(key);
> }
>
> public void clear() {
> configuration.clear();
> }
>
> }
>
>
> ------------------------------------------------------------------------
>
> package org.apache.commons.configuration;
>
> /* ====================================================================
> * The Apache Software License, Version 1.1
> *
> * Copyright (c) 1999-2003 The Apache Software Foundation. All rights
> * reserved.
> *
> * Redistribution and use in source and binary forms, with or without
> * modification, are permitted provided that the following conditions
> * are met:
> *
> * 1. Redistributions of source code must retain the above copyright
> * notice, this list of conditions and the following disclaimer.
> *
> * 2. Redistributions in binary form must reproduce the above copyright
> * notice, this list of conditions and the following disclaimer in
> * the documentation and/or other materials provided with the
> * distribution.
> *
> * 3. The end-user documentation included with the redistribution, if
> * any, must include the following acknowledgement:
> * "This product includes software developed by the
> * Apache Software Foundation (http://www.apache.org/)."
> * Alternately, this acknowledgement may appear in the software itself,
> * if and wherever such third-party acknowledgements normally appear.
> *
> * 4. The names "The Jakarta Project", "Commons", and "Apache Software
> * Foundation" must not be used to endorse or promote products derived
> * from this software without prior written permission. For written
> * permission, please contact apache@apache.org.
> *
> * 5. Products derived from this software may not be called "Apache"
> * nor may "Apache" appear in their names without prior written
> * permission of the Apache Software Foundation.
> *
> * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
> * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
> * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
> * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
> * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
> * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
> * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
> * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
> * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> * SUCH DAMAGE.
> * ====================================================================
> *
> * This software consists of voluntary contributions made by many
> * individuals on behalf of the Apache Software Foundation. For more
> * information on the Apache Software Foundation, please see
> * <http://www.apache.org/>.
> */
>
> import java.io.File;
> import java.io.FileWriter;
>
> import junit.framework.TestCase;
>
> /**
> * Test case for the ReloadableConfiguration class.
> *
> * @author Emmanuel Bourg
> * @version $Revision$, $Date$
> */
> public class TestReloadableConfiguration extends TestCase {
>
> public void testAutomaticReloading() throws Exception {
>
> // create a new configuration
> File file = new File("testReload.properties");
>
> try {
> FileWriter out = new FileWriter(file);
> out.write("string=value1");
> out.flush();
> out.close();
>
> // load the configuration
> PropertiesConfiguration pc = new PropertiesConfiguration("testReload.properties");
> pc.setFileName("testReload.properties");
>
> ReloadableConfiguration rc = new ReloadableConfiguration(pc);
> rc.setAutoReload(false);
> assertEquals("Initial value", "value1", rc.getString("string"));
>
> Thread.sleep(500);
>
> // change the file
> out = new FileWriter(file);
> out.write("string=value2");
> out.flush();
> out.close();
>
> // test the automatic reloading
> assertEquals("Modified value with disabled reloading", "value1", rc.getString("string"));
> rc.setAutoReload(true);
> assertEquals("Modified value with enabled reloading", "value2", rc.getString("string"));
> } finally {
> // delete the test file
> file.delete();
> }
> }
>
> }
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] Automatic reloading
Posted by Emmanuel Bourg <e....@cross-systems.com>.
He is an implementation of the reloadable decorator suggested by Eric. I
have also added a set/getRefreshDelay method.
Emmanuel Bourg
Eric Galluzzo wrote:
> Alternatively, it might be nice to introduce a FileConfiguration
> interface that just has a java.io.File getFile() method. Both
> DOM4JConfiguration and PropertiesConfiguration would implement this.
> Then one could repackage your existing ReloadablePropertiesConfiguration
> as a ReloadableConfiguration that implements Configuration but delegates
> to another FileConfiguration and checks the file every so often. Thus:
>
> Configuration config = new ReloadableConfiguration(
> new DOM4JConfiguration( myXMLFile ) );
>
> or
>
> Configuration config = new ReloadableConfiguration(
> new PropertiesConfiguration( myPropFile ) );
>
> This is a Decorator design reminiscent of FilteredOutputStream and
> FilteredInputStream.
>
> - Eric
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
RE: [configuration] Automatic reloading
Posted by Eric Pugh <ep...@upstate.com>.
That would be very cool, however we don't have that yet.. Someone did
suggest implementing a ReloadableConfiguration decorator. However, the only
work has been done was on one for the file decorator.. It does seem like
the refreshDelay ought to be settable via the <configuration/> xml...
Eric
> -----Original Message-----
> From: Tim Reilly [mailto:tim.reilly@consultant.com]
> Sent: Tuesday, December 16, 2003 4:46 AM
> To: Jakarta Commons Developers List
> Subject: RE: [configuration] Automatic reloading
>
>
> First, thanks for contributing this.
>
> I was hoping something like this was possible?
> <configuration>
> <jndi prefix="java:comp/env"/ refreshDelay="[milliseconds]">
> <properties fileName="conf/test.properties"/>
> <dom4j fileName="conf/test.xml"/ refreshDelay="[millseconds]">
> </configuration>
>
>
>
>
> > -----Original Message-----
> > From: Eric Galluzzo [mailto:egalluzzo@einnovation.com]
> > Sent: Monday, December 15, 2003 12:28 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [configuration] Automatic reloading
> >
> >
> > Emmanuel Bourg wrote:
> >
> > > I wonder if it is desirable to change the PropertiesConfiguration
> > > class or extend it as a ReloadablePropertiesConfiguration
> class. What
> > > would be the best approach ? Also the same feature could be
> > > implemented for the DOM4JConfiguration class. If so we
> might want to
> > > introduce a ReloadableConfiguration interface defining the
> > > is/setAutoReload and get/setRefreshDelay methods.
> >
> > Alternatively, it might be nice to introduce a FileConfiguration
> > interface that just has a java.io.File getFile() method. Both
> > DOM4JConfiguration and PropertiesConfiguration would
> implement this.
> > Then one could repackage your existing
> ReloadablePropertiesConfiguration
> > as a ReloadableConfiguration that implements Configuration
> but delegates
> > to another FileConfiguration and checks the file every so
> often. Thus:
> >
> > Configuration config = new ReloadableConfiguration(
> > new DOM4JConfiguration( myXMLFile ) );
> >
> > or
> >
> > Configuration config = new ReloadableConfiguration(
> > new PropertiesConfiguration( myPropFile ) );
> >
> > This is a Decorator design reminiscent of FilteredOutputStream and
> > FilteredInputStream.
> >
> > - Eric
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [configuration] Automatic reloading
Posted by Tim Reilly <ti...@consultant.com>.
First, thanks for contributing this.
I was hoping something like this was possible?
<configuration>
<jndi prefix="java:comp/env"/ refreshDelay="[milliseconds]">
<properties fileName="conf/test.properties"/>
<dom4j fileName="conf/test.xml"/ refreshDelay="[millseconds]">
</configuration>
> -----Original Message-----
> From: Eric Galluzzo [mailto:egalluzzo@einnovation.com]
> Sent: Monday, December 15, 2003 12:28 PM
> To: Jakarta Commons Developers List
> Subject: Re: [configuration] Automatic reloading
>
>
> Emmanuel Bourg wrote:
>
> > I wonder if it is desirable to change the PropertiesConfiguration
> > class or extend it as a ReloadablePropertiesConfiguration class. What
> > would be the best approach ? Also the same feature could be
> > implemented for the DOM4JConfiguration class. If so we might want to
> > introduce a ReloadableConfiguration interface defining the
> > is/setAutoReload and get/setRefreshDelay methods.
>
> Alternatively, it might be nice to introduce a FileConfiguration
> interface that just has a java.io.File getFile() method. Both
> DOM4JConfiguration and PropertiesConfiguration would implement this.
> Then one could repackage your existing ReloadablePropertiesConfiguration
> as a ReloadableConfiguration that implements Configuration but delegates
> to another FileConfiguration and checks the file every so often. Thus:
>
> Configuration config = new ReloadableConfiguration(
> new DOM4JConfiguration( myXMLFile ) );
>
> or
>
> Configuration config = new ReloadableConfiguration(
> new PropertiesConfiguration( myPropFile ) );
>
> This is a Decorator design reminiscent of FilteredOutputStream and
> FilteredInputStream.
>
> - Eric
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] Automatic reloading
Posted by Eric Galluzzo <eg...@einnovation.com>.
Emmanuel Bourg wrote:
> I wonder if it is desirable to change the PropertiesConfiguration
> class or extend it as a ReloadablePropertiesConfiguration class. What
> would be the best approach ? Also the same feature could be
> implemented for the DOM4JConfiguration class. If so we might want to
> introduce a ReloadableConfiguration interface defining the
> is/setAutoReload and get/setRefreshDelay methods.
Alternatively, it might be nice to introduce a FileConfiguration
interface that just has a java.io.File getFile() method. Both
DOM4JConfiguration and PropertiesConfiguration would implement this.
Then one could repackage your existing ReloadablePropertiesConfiguration
as a ReloadableConfiguration that implements Configuration but delegates
to another FileConfiguration and checks the file every so often. Thus:
Configuration config = new ReloadableConfiguration(
new DOM4JConfiguration( myXMLFile ) );
or
Configuration config = new ReloadableConfiguration(
new PropertiesConfiguration( myPropFile ) );
This is a Decorator design reminiscent of FilteredOutputStream and
FilteredInputStream.
- Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] Automatic reloading
Posted by Emmanuel Bourg <e....@cross-systems.com>.
Thank you for looking at the patch Eric,
Eric Pugh wrote:
> [configuration] Automatic reloadingEmmanuel,
>
> This looks good.. I don't have a problem applying this patch, but could we
> get a couple small changes?
>
> 1) Could you submit this as part of bugzilla? Makes it easier to list out
> the changes when we do a release.
Sure, I'll file a bug.
> 2) Can you submit all the files as a patches? It looks like the patches are
> only for the unit tests..
I have attached a diff and the full version of the modified files, i
think everything needed was there.
> 3) Can we make the sleep time configurable? default to 5 seconds, but allow
> it to change.. I can see some environments where we might want to check
> every minute or something.. Just seems like it should be configurable..
Ok
> 4) In the code there is a System.out.println, can we change that to use the
> standard logging scheme?
Actually I forgot to remove it before submiting the patch, it wasn't
supposed to be there ;)
I wonder if it is desirable to change the PropertiesConfiguration class
or extend it as a ReloadablePropertiesConfiguration class. What would be
the best approach ? Also the same feature could be implemented for the
DOM4JConfiguration class. If so we might want to introduce a
ReloadableConfiguration interface defining the is/setAutoReload and
get/setRefreshDelay methods.
Emmanuel Bourg
RE: [configuration] Automatic reloading
Posted by Eric Pugh <ep...@upstate.com>.
[configuration] Automatic reloadingEmmanuel,
This looks good.. I don't have a problem applying this patch, but could we
get a couple small changes?
1) Could you submit this as part of bugzilla? Makes it easier to list out
the changes when we do a release.
2) Can you submit all the files as a patches? It looks like the patches are
only for the unit tests..
3) Can we make the sleep time configurable? default to 5 seconds, but allow
it to change.. I can see some environments where we might want to check
every minute or something.. Just seems like it should be configurable..
4) In the code there is a System.out.println, can we change that to use the
standard logging scheme?
I am going to try and get a vote for moving to commons proper from sandbox.
so, we'll either get this in before the move, or just after the move...
Eric
-----Original Message-----
From: Emmanuel Bourg [mailto:e.bourg@cross-systems.com]
Sent: Thursday, December 11, 2003 4:27 PM
To: Jakarta Commons Developers List
Subject: [configuration] Automatic reloading
Greetings, I'd like to contribute a slight modification to reload
automatically a PropertiesConfiguration if the underlying .properties
file has been changed. I had to implement this to prevent restarting my
web application every time a configuration file is modified.
The auto reload mode is enabled by calling setAutoReload(true) on the
PropertiesConfiguration instance. It's disabled by default. Every time a
property is accessed with getXXX(key) the date of the file is checked
and the configuration is reloaded if the previous date known is older.
This check is executed only once every 5 seconds to prevent hammering
the file system.
I'm attaching the patch and the modified files to this mail, all test
cases passed successfully. I've also added a specific test case for the
automatic reloading scenario.
Emmanuel Bourg