Page History

...

This is less important to normal users of DSpace, but may be of high interest to developers and some system administrators.

Configuration variables determined at runtime

It's important to be aware of the fact that variables within the following types of configurations are now AUTOMATICALLY interpolated at runtime using Apache Commons Configuration (and our ConfigurationService). This means that variables (${setting}) are no longer filtered by Maven or Ant for any of the following configuration types. InsteadIn other words, all variables are perfectly OK in these configuration files are determined at runtime:in your DSpace installation directory (i.e. [dspace]).

• Primary Configuration files (namely local.cfg, dspace.cfg and all modules/*.cfg)
• Primary Log4j settings (log4j.properties)
• Spring XML configs (namely [dspace.dir]/config/spring/api/*.xml)

Configuration variables filtered during installation (prior to runtime)

There are a few configuration file(s) which still require their variables/settings to be filtered/interpolated manuallyduring installation. The following configuration files are still filtered during the Installation/Update process (ant fresh_install or ant update), and cannot be determined at runtime:.  In other words, variables cannot exist in these configuration files in your DSpace installation directory (i.e. [dspace]).

• web.xml files still require filtering, both web.xml files still require filtering, both to support IDE integration, and to properly initialize all webapps in general:your Servlet Container (e.g. Tomcat).
  
  • To support IDE integration (and allow debugging of webapps from IDEs), all web.xml files are filtered by Maven using the filteringDeploymentDescriptors setting in POMs. Without this setting, the web.xml files will never be filtered when attempting to run any DSpace webapp from within an IDE.
  • Additionally, to support running the webapps in general, the ${dspace.dir} variable is also filtered (by Ant). This is because the dspace.dir context parameter in these web.xml files is used to initialize the DSpace Kernel (and tell the webapp where the DSpace home directory is). Unfortunately, there's no way to interpolate this value at runtime as the dspace.dir value does not exist until the Kernel and the ConfigurationService have initialized
    The only way we'd get around this problem would be to REQUIRE a dspace.dir ALWAYS be specified to the servlet container (as a Context parameter and/or system property).
    • In other words, the DSpace webapps cannot function/initialize without a dspace.dir.  We either need to filter a value for it (during ant update/fresh_install), or we need to REQUIRE that it be specified by other means.
    • The only way we'd get around this problem would be to REQUIRE a dspace.dir ALWAYS be specified to the servlet container (as a Context parameter and/or system property).
• robots.txt : Obviously there's no way for a static file like robots.txt to load configurations at runtime. This file is filtered by Ant during a "fresh_install" or "update".
• log4j-*.properties : While the primary log4j.properties configuration is NOT filtered, DSpace also includes several other log4j files which are utilized by third-party dependencies (e.g. Solr uses its own log4j-solr.properties). As these third-party dependencies have their own initialization process, they cannot utilize DSpace's ConfigurationService, and their log4j configurations must be filtered by Ant during a "fresh_install" or "update".
• RDF configurations: The DSpace RDF / Linked Data interface has TTL configuration files which require minor filtering. These files are filtered by Ant during a "fresh_install" or "update".
• OAI-PMH description.xml: This static, custom OAI-PMH configuration file requires minor filtering. This file is filtered by Ant during a "fresh_install" or "update".

...