Pattern - Configuration in source files

One place to store configuration data is inside source files themselves. This is easy for developers to do, whether or not it was what they intended.

There are a number of ways in which the information can be encoded, including

1. As inline strings and numbers.
2. As language constants, separate from the location in which they are used
3. As metadata attributes in the source code
4. As fragments of code which dynamically configure the system in which they run

Some examples of this include:

1. JSP/HTML pages that contain hard coded links to other pages in the site.
2. Java source files that contain EJB3 metadata declaring the database binding of their persistent classes.
3. Programs which dynamically configure an in-process web server (such as Jetty) without offering any configuration options.
4. Web Services in which some of the configuration settings (remote URL) are hard coded into source generated from WSDL.

Features

• Configuration data is stored in the source files.
• If the source is under SCM, so are the configuration options.

Advantages

• Some type checking at compile time may identify type problems before deployment commences
• If configuration is set by shared constants, a change to that constant will rapidly propagate.
• Easy for developers to read/write the values.
• Keeps the configuration under SCM.
• Ensures that nobody changes the configuration values in production systems.
• Any tool that generates source code can generate configuration information.
• No need for external configuration management tools.
• The less configuration options there are, the less testing, documentation and configuration problems you have.

Disadvantages

• Only one configuration is allowed, unless a (complex) override mechanism is supported.
• To change the configuration, a complete rebuild is needed.
• If the configuration constants are scattered around an application, it is hard to locate them.
• If the constants are replicated all round the application (such as in HTML pages) it is very hard to change them.
• The consequences of 'minor' metadata changes can be quite significant.

Because a complete rebuild is needed, the cost of changing configuration information embedded in Java source is high. However, in languages which are directly interpreted, the cost is much lower; there is no need to recompile anything. Indeed, changes can be made to the source files in a deployed installation. This does not mean that editing configuration information in this manner is a wise move, merely that it is possible.

Encoding configuration information into source does make sense is if you intend to eliminate any configuration options. For example, a program could decide to always use the standard temp file directory, rather than offer a way to configure the temporary directory. Removing this configuration option eliminates the need to read for the value (and pick a default), it reduces the risk of the temporary directory being missing/unwriteable (it may be, but more will break than just your application), and it simplifies application testing (one less option to try out) and documentation (one less option to document).

Where it falls down is if you do suddenly need to make that option configurable, you have a problem. In this situation, the solution is to make the options configurable when the need to configure them arises. Until then, hard coded options in source (preferably as constant strings whose use your IDE can locate), are workable. But please, not hard-coded URLs in HTML pages, as they are a maintenance nightmare.

SmartFrog support

This is something we've avoided. For SmartFrog's own components, we try and drive everything through configuration data. Many components do, however, have default values set in Java source, default values that can be (optionally) overridden. More recent components tend to be written assuming no default values, and requiring values to be set in the base template. This makes those default values more explicit to people viewing the source file.