Auto refreshing properties from property files

Source code available @
svn checkout https://whiteboardjunkie.googlecode.com/svn/trunk/properties-dynaload properties-dynaload
Browse Source code here

I have written a tool to automatically reload a property file on file change. This tool came very handy when implementing stand alone server applications that cannot resort to a server restart for refreshing properties. The class itself is a simple construct that spawns a LOW_PRIORITY thread to monitor the property file and reload the properties when the file has changed. To address some specific use cases where the system should be notified of such a reloading of properties I have also provided a mechanism to add listeners. In the following sample snippet an instance of AutoRefreshingProperties is instantiated against ‘config/configuration.properties’. We are also adding two listeners who are interested to know of any file changes.

	static final File destFile = new File("target/test-classes/config/configuration.properties");
	static Properties properties = null;
	@BeforeClass
	public static void beforeClass() throws Exception{
		properties = new AutoRefreshingProperties(null,destFile.getAbsolutePath())
					.addListener(new FileChangeAdapter() {
						@Override
						public void notifyFileChanged(Properties properties) {
							System.out.println("LISTENER1 : Properties have changed...");
							System.out.println("my.property1=" + properties.getProperty("my.property1"));
						}
					})
					.addListener(new FileChangeAdapter() {
						@Override
						public void notifyFileChanged(Properties properties) {
							System.out.println("LISTENER2: Properties have changed...");
							System.out.println("my.property1=" + properties.getProperty("my.property1"));
						}
					});
	}

To test whether the gig really works we are then changing the contents of the properties file by copying over another properties file to the same location. From my experience I can relate to this test case very well since there are dozens of instances where restarting a running server is not an option to change a simple property.

		copyNewPropertiesFile("target/test-classes/master-config/configuration1.properties");
		Thread.sleep(4);
		assertEquals("foo1", properties.getProperty("my.property1"));
	}

	private synchronized void copyNewPropertiesFile(String fromPath)throws Exception{
		FileUtils.copyFile(new File(fromPath), destFile);
	}

The resulting output clearly shows that the test passes, the properties have changed and both the notifiers are notified.

/*
-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.boni.dynaload.TestDynamicPropertyLoading
LISTENER1 : Properties have changed...
my.property1=foo
LISTENER2: Properties have changed...
my.property1=foo
LISTENER1 : Properties have changed...
my.property1=foo1
LISTENER2: Properties have changed...
my.property1=foo1
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
*/

The source code that did this auto loading is not very complex either. It extends the java.util.Properties and adds a new constructor that accepts an absolute file path as the location of the property file that needs auto loading. This suffices the problem I am trying to solve since it is highly unlikely that one needs to change a property file embedded in a jar file. More often than not a fix folder (say ‘config’) houses the configuration files and this folder is added to the classpath.

class AutoRefreshingProperties extends Properties{
	private long LAST_LOADED = System.currentTimeMillis();
	private List listeners = Collections.synchronizedList(new ArrayList());
	public AutoRefreshingProperties(String absolutePathToPriopertiesFile) throws IOException{
		this(null, absolutePathToPriopertiesFile);
	}
	public AutoRefreshingProperties(Properties defaults, String absolutePathToPriopertiesFile) throws IOException{
		super(defaults);
		load(absolutePathToPriopertiesFile);
	}
	public AutoRefreshingProperties removeListener(FileChangeListener listener){
		listeners.remove(listener);
		return this;
	}
	public AutoRefreshingProperties addListener(FileChangeListener listener){
		listeners.add(listener);
		return this;
	}
	public synchronized void load(String absoluteFilePath) throws IOException {
		InputStream is = new FileInputStream(new File(absoluteFilePath));
		this.load(is);
		LAST_LOADED = System.currentTimeMillis();
		keepUpdated(absoluteFilePath);
	}
	abstract class FileWatcher implements Runnable{} 
	private void keepUpdated(final String absoluteFilePath){
		Executors.newSingleThreadExecutor().submit(
				new FileWatcher(){
					@Override
					public void run() {
						try {
							while(true){
								if (new File(absoluteFilePath).lastModified() > LAST_LOADED){
									InputStream is =  new FileInputStream(new File(absoluteFilePath));
									load(is);
									LAST_LOADED = System.currentTimeMillis();
									notifyListeners();
								}
								Thread.yield();
								Thread.sleep(2000);
							}
						} catch (Exception e) {
							e.printStackTrace();
						}
					}
				}
		);
	}
	private void notifyListeners(){
		final Properties properties = new Properties(this);
		for (FileChangeListener aListener : listeners){
			aListener.notifyFileChanged(properties);
		}
	}
}

In the simplest of usage scenarios all you will need to do the auto loading feature is to just create an instance of AutoRefreshingProperties by passing the path to the properties file. The class will take care of monitoring the file and reloading itself on file change. So at any point of tile when the system makes a call to Properties.getProperty(…) it will return the latest value specified in the properties file. As I have shown in the test case the power of this tool can be extended by attaching listeners and taking appropriate reactive actions on property changes.

The feature that I would love to see augmented to such a solution is how a spring bean property configured through PropertyPlaceholderConfigurer can load an refresh the beans on property file changes. In my opinion that solution will not be as trivial as the one I cooked up here. Having said that one can very easily use the notification listener mechanism to do whatever it needs to do on such an event.

JDK7 has a WatchService specificatiion. The b64 release has this interface in place. Such a support from JVM will alleviate a lot of thread management issues that each of us have cooked up for file and directory monitoring.

About these ads