Webapp configuration.

« Back on the grid. | Main | Castor JDO: false... »

Webapp configuration.

I have two complaints with the XML-file approach to webapp configuration approach that <a href= "http://freeroller.net/page/jduska/20021206#how_to_handle_configuration_information">Jeff and <a href= "http://www.raibledesigns.com/page/rd/20021206#webapp_configuration">Matt have been discussing (and the one that Roller currently uses):

It does not work well in a distributed situation. If my application is distributed across multiple servers, then app instances cannot easily share one XML file. In that case, I'd need to copy the XML file to every server. If I want to make configuration changes while the app is running then I'm are out of luck. A better approach would be to store this type of information in a database, not a file.
There is no meta-data. I would rather not have to write a configuration UI for every webapp that I write. But, to write a generic configuration editor UI, I need to have meta-data about each configuration property. For strings and string-list properties, I'd want a list of possible values. For integer properties , I'd want a range. For a real configuration API, I need meta-data about properties and acceptible values.

Is there a configuration or preferences API that supports meta-data? I don't believe that the Java 1.4 preferences API does this. I wonder why not? Maybe Sun was just trying to replicate the Windows Registry.

Dave Johnson in Java 12:14PM Dec 07, 2002 Comments [4]
Tags: Java

Comments:

To comment on your first point. While it doesn't give you nice access like a database does - if you store the configuration in the servletcontext, and only load it at startup, it will give you access to those variables in a clustered situation. And less overhead than a database. I like it because it makes it easy to setup servers with different parameters easily. It's been working great for us - we have 10 tomcat instances setup on one Linux server, proxied through Apache and every instance has their own setup and app.

Posted by Matt Raible on December 08, 2002 at 03:00 PM EST #

Also remember that if you load your XML configuration file from a URL (rather than a file name) then the XML file can be generated dynamically by some other process.

e.g. you could have a web application generating your configuration information dynamically from a database, a web service, some template mechanism etc.

Posted by James Strachan on December 09, 2002 at 03:54 PM EST #

I have to say that having done it all possible ways, Dave is pretty on the mark. The best configuration should be no configuration. Loading files? Noway man! Loading from a URL? Talk about pain! Everything should be a resource loaded from the classpath, and NOTHING should be file system specific if you can avoid it. Put as much configuration information as possible in the database. Use simple, sensible defaults (remember - 90% of users will never change them anyway). Use XML files to load those defaults if you want. My $0.02. -mike

Posted by Mike Cannon Brookes on December 10, 2002 at 06:18 AM EST #

I'd just like to second Mike. In our project we've started with a simple properties file, moved to a database solution and are now caching those entries via Javagroups. With that it's easy to update values (with or without a special front-end), to handle different configurations per server, to notify changes in a cluster. Of course it depends on the scope of your project, for most a database option is over-kill- but if you can use one, use it. Similar answer for 0.02 Euros

Posted by Fabian Crabus on December 10, 2002 at 11:12 AM EST #

Welcome

This is just one entry in the weblog Blogging Roller. You may want to visit the main page of the weblog

Related entries

Below are the most recent entries in the category Java, some may be related to this entry.