Properties files are simple ways to manage the variable aspects of application configuration. One pain point I have experienced is the lack of an elegant way to auto load properties file when it changes after the application has started. This problem prevails in many JEE application servers and in all stand alone Java applications. In this blog post I am discussing a solution to solve the auto loading of properties file when it changes outside the file system. http://whiteboardjunkie.wordpress.com/2009/10/13/auto-refreshing-properties-from-property-files/ The solution outlined extends java.util.Proiperties by adding a new constructor that accepts an absolute path to the properties file as an argument. It then spawn a LOW_PRIORITY thread to monitor the property file for changes. To lend more power to this simple solution the notion of FileChangeListener is introduced. Read on..Happy coding!!

Commons-Config has already solved this problem: http://commons.apache.org/configuration/userguide/howto_filebased.html#Automatic_Reloading I don't want to demean your coding skills, but to post this on TSS as "News" would seem to suggest this is a novel or new solution. Sure, this is a great tutorial and perfectly suitable for a blog post (and probably JavaRanch) but TSS' "News" feed does not seem all that appropriate IMO. Sorry. In fact, people seem to post their own blogs or random questions to the TSS news feed quite often, which is incredibly annoying. That's why I get most of my news from InfoQ these days.

Or if your use case involves updating the properties often, wouldn't you want to consider placing them in a database table? In that way you can put constraints on what values you want to accept or not. And you get the database features like consistency, security etc, for free.

Similarly, Log4j has had the notion of configure-and-watch in their PropertyConfigurator for years. I'm not sure you could use the class directly, but you might as well look at how it works before coming up with a totally fresh implementation. --Matt The Software Grove

I agree that this was not newsworthy. I hope most TSS readers could figure this problem out by themselves.

Take it easy guys :-). Somehow I missed the Commons Configuration. Thanks for pointing it out to me. Ohh, this blog post is no way a TSS Newsworthy item - I agree!. Posted only because I saw a few discussions with no solutions around google search. As I mentioned in the blog this is just solve a problem that I was having for a few stand alone server applications built recently.

The real problem is not the dynamic loading of properties, but the consequences that it can have in your application. Your application can become data inconsistent or even unstable after a dynamic reload of properties. I would not recommend this unless you are very sure that it has no severe impact on your current running instance.

This is great. Thx for pointing towards the apache project. This is exactly what we needed in our current project and it integrated nicely. And thx Boni for starting this conversation which led to these findings.

http://easyconf.sourceforge.net/ Liferay Portal Server uses this and it seems to work great.

It is not a practice to start new threads in application servers, except from specialized threads that are managed by the server itself. I would recommend two different approaches (why waste precious processor cycles :-)): 1. use JMX and create your properties reader as mbeans 2. use singleton to load properties once, and than use external web service or something that will reload properties(you can also add a web interface to change properties values). These days you can write a JRuby Rails application in few minutes that will serve the purpose.

Let me give some background to set the context. There are various use cases where you need to reload the properties and where you are not using an application server to scaffold your application. For example an image analysis server I recently wrote needs external configuration support to tune its cache configurations. Another use case is where I wanted to add a new set of Encode-Decode classes by specifying the classnames as properties. In a third instance the running server needs references (ip) to one more image server so that it can keep a channel open. In simpler cases we might want to push in a new smtp server location or the archival location. In mission critical yet minimalistic applications restarting is seldom an option. This is further validated by the existence of the auto reloading feature in the apache commons configurations. What I would really like to see is a smart,elegant and generic solution to auto reload spring context beans.

It is not a practice to start new threads in application servers, except from specialized threads that are managed by the server itself.

I would recommend two different approaches (why waste precious processor cycles :-)):
1. use JMX and create your properties reader as mbeans
2. use singleton to load properties once, and than use external web service or something that will reload properties(you can also add a web interface to change properties values). These days you can write a JRuby Rails application in few minutes that will serve the purpose.

As such, it is extremely bad practice to create and *write* to files directly in application servers. Almost all applications running in applications servers eventually do this using something like log4j, since the logging mechanisms of the applicatio servers themselves are either not sufficient or not properly documented. If you engineer your thread in such a way that it is not interfering with redeployment and stopping and starting of the server, this should not pose a problem after all. Also, even simpler, why not expire a property file and simply reload it after a given period of time without spawning a thread. Given what the processes that use such configuration typically do (database access, calling weg services ...) , re-reading a property file does normally have no severe performance impact. Not that I think that the overall task is much of a problem nowadays anyway.

This is solved (watching files) in NIO.2: http://java.sun.com/developer/technicalArticles/javase/nio/ Peace, Cameron Purdy | Oracle Coherence