Settings are read using methods in the class dk.netarkivet.common.utils.Settings.The declaration of the settings themselves, however, have been moved to new settings classes in each of the modules. Every module except for the Deploy module have its own Settings class and a settings.xml file containing the default values for the module settings.
In addition to that, every plug-in is intended to declare its own settings inside itself, and be associated with an xml-file containing the default values of these settings placed in the same directory as the plugin itself. For more information, please refer to the Configuration Basics description in the Configuration Manual.
Associated with most of the NetarchiveSuite plug-ins, there are also factory classes that hides the complexity behind selecting the correct plugin according to the chosen settings. The names of these classes all ends on Factory, e.g. JMSConnectionFactory, RemoteFileFactory.
Almost all configuration of NetarchiveSuite is done through the main module Settings classes as for example the dk.netarkivet.common.Settings class. It provides a simple interface to the settings.xml file as well as definitions of all current configuration default settings. The settings.xml file itself is an XML file with a structure reminiscent of the package structure.
Settings are referred to inside NetarchiveSuite by their path in the XML structure. For instance, the storeRetries setting in arcrepositoryClient under common is referred to with the string settings.common.arcrepositoryClient.storeRetries. However, to avoid typos, each known setting has its path defined as a String constant in a module Settings class(e.g. HarvesterSettings), which is used throughout the code (also by deploy in checks of whether the settings are known). The module Settings class file also includes description of the setting in their javadoc.
To add a new general setting, the following steps need to be taken:
1) The Settings class should get a definition for the path of the setting. This String, although a constant, must mot be declared final since settings are initialised by a static initialiser in the class
2) Javadoc for the definition must including the path name of the setting as well as description of the setting.
3) All default settings.xml files must be updated (including those in the unit tests).
4) examples/settings_example.xml must be updated.
Note that there are no XML Schema to be updated, because the use of default settings means that a settings file does not need to be there, and in the case of settings for plug-ins we generally do not know which setting will be used.
Note also that the Configuration Manual includes a description of how deploy can be used to validate whether the settings in a settings file are valid (not necessarily exhaustive!).