I have a web app with a property file for all language depending strings, which works great! :-)
Now I'd like to allow the super-user to update that file from the browser. As it is currently part of my WAR file, I don't want to change that on the runtime.
Where and how would you save the properties?
- in an exerrnal file (outside of application.war)
- in the DB
Prior to the introduction of the Preferences API, developers could choose to manage preference and configuration data in an ad hoc fashion, by using the Properties API or the JNDI API as described below.
Often, preference and configuration data was stored in properties files, accessed through the java.util.Properties API. However, there are no standards as to where such files should reside on disk, or what they should be called. Using this mechanism, it is extremely difficult to backup a user's preference data, or transfer it from one machine to another. As the number of applications increases, the possibility of file name conflicts increases. Also, this mechanism is of no help on platforms that lack a local disk, or where it is desirable that the data be stored in an external data store (such as an enterprise-wide LDAP directory service).
Less frequently, developers stored user preference and configuration data in a directory service, accessed through the Java Naming and Directory Interface (JNDI) API. Unlike the Properties API, JNDI allows the use of arbitrary data stores (back-end neutrality). While JNDI is extremely powerful, it is also rather large, consisting of 5 packages and 83 classes. JNDI provides no policy as to where in the directory name space the preference data should be stored, or in which name space.
Neither Properties nor JNDI provide a simple, ubiquitous, back-end neutral preferences management facility. The Preferences API does provide such a facility, combining the simplicity of Properties with the back-end neutrality of JNDI. It provides sufficient built-in policy to prevent name clashes, foster consistency, and encourage robustness in the face of inaccessibility of the backing data store.
I read somewhere that properties files merely have to be in the class path. If this is true, then you could maintain the properties files outside of your deployment archive. Of course, this brings up the problem of application management.
Alternatively, you could keep the strings in a database, and devise a scheme to use the properties files to provide pointers to the appropriate records.
I haven't tried this... I just "thinking out loud," so to speak.