## page was renamed from Developer Manual 3.14/Coding Guidelines - Design Related <> <> == Settings == <> '''''Also include relevant parts to the design decision input document (is now implemented) <>''''' 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 <>. 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 the ~+`Settings`+~ class, which is used throughout the code (also deploy in checks of whether the settings are known). The ~+`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 1. Javadoc for the definition must including the path name of the setting as well as description of the setting. 1. all default ~+`settings.xml`+~ files must be updated (including those in the unit tests). 1. ~+`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 the <> includes a description of how deploy can be used to validate whether the settings in a settings file are valid (not necessarily exhaustive!). <> <> <> <> <>