• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

About JForum2's configuration system

 
Ranch Hand
Posts: 41
10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
  • Backup storage
  • 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.
    reply
      Bookmark Topic Watch Topic
    • New Topic