Post-Installation Configuration File Editing

After installing a web application, it is (often manually) configured. This can take the form of editing a configuration file in the (expanded) web application, or it can be done by a web-based GUI in the now-deployed application, a GUI that writes its changes back to the expanded file system.

Examples this include

• Confluence; the file WEB-INF/classes/confluence-init.properties needs editing to initialize confluence.
• Cruise Control -you need to edit webapps/cruisecontrol/WEB-INF/web.xml to point the reporting web site at Cruise Control itself.
• Jira The subversion plugin is configured by editing the file WEB-INF/classes/subversion-jira-plugin.properties

This same process is also implemented in all Java applications that offer a file in which options such as maximum memory and proxy properties can be set. This includes SmartFrog's default.ini along with those of every Java IDE. Implicitly it includes the startup batch files of Tomcat and other application servers.

Features

• A single WAR file is deployed to all systems
• This WAR file is customised after deployment, by altering files in the web application

Advantages

• No need to generate multiple WAR files.
• No need to implement complex configuration GUIs/installers.
• It is possible to automate configuration, through a deployment workflow that creates/edits the specific configuration files after expanding the web application.
• With file-based configurations, different installations on the same host can have different values.
• Backup of the files copies the configuration data; copying the files shares it across hosts.

Disadvantages

• Configuration information is not (normally) kept under SCM.
• Manual editing errors (especially of the web.xml file) can break the web application, leading to support calls.
• Complicates the upgrade/uninstall process.

The upgrade process is one of the hardest problems to manage, as the existing customisations need to be carried forwards. RPM installations can have specific files marked as configuration files, in which case they will not be deleted or overwritten when updated:

%config(noreplace) %{bindir}/default.sf

Shell scripts are not normally marked as configuration files, so if someone edits an application server's startup script to request extra JVM memory, this configuration option will be lost the next time a new RPM is rolled out.

If a new (required) configuration parameter is added to an existing configuration file, then migration is a problem. The existing file cannot be carried forwards, instead the old configuration has to be merged with the new one. This process is generally left to the user.

In the windows ecosystem, these configuration options are invariably left to The Windows Registry.

SmartFrog support

The basic filesystem manipulation components (Copy, TextFile, etc) can be used to set up text files. There is nothing explicit to set up Property files. The sf-xml components can assist with XML file creation.

For products that look for specific properties files on the classpath, setting up the classpath of the specific application server instance can make the files available, without having to alter the contents of the WAR file itself. For example, Log4J options could be set by creating a new, temporary log4j.properties file and adding it's parent directory to the classpath. If the application server follows normal classpath inheritance rules, this file will be visible to deployed web applications.