Page History

...

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. Instead, all variables in these configuration files are determined at runtime:

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

There is only one remaining file type which still requires its configurations/are a few configuration file(s) which still require their settings to be filtered/interpolated manually. The following configuration files are filtered during the Installation/Update process (ant fresh_install or ant update), and cannot be determined at runtime:

• All web.xml files unfortunately still need to have their ${dspace.dir} variable filtered (by Ant). This is because the dspace.dir context parameter in these web.xml files is require filtering, both to support IDE integration and to properly initialize all webapps in general:
  
  • 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.

Java API Changes

• 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".

Java API Changes

ConfigurationManager vs ConfigurationService

...

PluginManager vs PluginService

In DSpace 5, the org.dspace.core.PluginManager class managed all , the org.dspace.core.PluginManager class managed all DSpace "plugin" definitions (i.e. plugin.* settings in dspace.cfg). (SIDENOTE: these DSpace "plugin" definitions (i.e. plugin.* settings in dspace.cfg). (SIDENOTE: these DSpace "plugin" definitions are simply Java interfaces, which are then mapped to classes which implement that plugin interface).are simply Java interfaces, which are then mapped to classes which implement that plugin interface).

While this concept still exists (and all plugin configurations are still respected/valid), the PluginManager itself has been entirely replaced by a new org.dspace.core.service.PluginService. This change was necessary in order to "Spring-ify" the PluginManager and make it compatible with the ConfigurationService. In prior releases (5.x and below), the PluginManager was highly dependent on the ConfigurationManager, and as such, did not respect/follow the Spring bean initialization process. In other words, without this major refactor, the PluginManager would attempt to request configurations from the ConfigurationService before the ConfigurationService was fully initialized by SpringWhile this concept still exists, the PluginManager itself has been entirely replaced by a new org.dspace.core.service.PluginService.

The default PluginService is a new org.dspace.core.LegacyPluginServiceImpl class, which implements the functionality of the old PluginManager.

...