Note: most of this post refers to the bugfix version posted on Google code. To make this point a little clearer, the post will continually refer to JForum2, but this does not mean the original JForum (now on a version 2) - it means the Google Code bugfix versions. Specifically, 2.3.4. This is important, as in the area of configuration, the bugfix version has reworked the original code.
Background JForum2 has a rather splendid system for loading configuration. Out of curiosity it's possible users may wish to know about the system. More practically, much time in configuration can be saved if the abilities of the system are known beforehand.
JForum2 uses several properties files, located in /WebContent/WEB-INF/config. Some of these provide SQL queries, etc. The most interesting to a usr is SystemGlobals.properties. Some of these values can be overridden from the Admin interface, but not all.
Features of the configuration system JForum2 does not use a simple 'properties file' loader. There are several classes handing configuration loading. Here is a list of features,
The properties are written to system variables.
Ok, this means they become global, and there are many arguments about global variables, but this means the variables are available, through a defined API, for use throughout code.
By simple methods, a configuration can be stored.
Transient values and object map also available.
Using the same API, transient (not stored) values, and ObjectValues, a map of whole Objects, can be stored.
Default configurations are provided, and configurations can be appended.
The system uses classes packed with static methods and fields.
Not singletons, but classes of static calls carrying instances of themselves. It means the loading is consistent and available across servlets. Considering the threaded nature of Servlets, this is cool.
The system heavily namespaces all the variables
Which removes some/many arguments against the implementation style described above.
The variables are cross-checked
Variables must match the entries in the file net.jforum.utils.preferences.ConfigKeys. This means that the properties are specified and tightly controlled. This is probably a good thing, and a note in the file says it also triggers Eclipse autofills (on the other hand, it makes extensions difficult).
The system listens to the state of variables
A feature with zero publicity, but plainly of great interest. Change a variable, and there is no need to recompile, or even redeploy. The variable becomes active within a second or so.
If you are glancing down this post before configuration, note in particular that the JForum2 configuration system listens and reacts to changes in files.