This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Servlets and the fly likes Update properties at runtime Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "Update properties at runtime" Watch "Update properties at runtime" New topic
Author

Update properties at runtime

Martin Habicht
Greenhorn

Joined: Nov 07, 2001
Posts: 17
Hi
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
- ?!?

thanks
Martin
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
hmmmm . . . I think that that was why Preferences were developed. They facilitate update to the values during runtime (as well as other advantages).

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.


"JavaRanch, where the deer and the Certified play" - David O'Meara
Philip Shanks
Ranch Hand

Joined: Oct 15, 2002
Posts: 189
I'm really not a big fan of the Preferences API. (See this to learn why).
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.


Philip Shanks, SCJP - Castro Valley, CA
My boss never outsources or has lay-offs, and He's always hiring. I work for Jesus! Prepare your resume!
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Update properties at runtime