...
| Note | ||
|---|---|---|
| ||
As noted above, by default, DSpace will now automatically reload any modified configuration file ( While the new values are immediately available within the DSpace ConfigurationService, some configurations may still be "cached" within UI-specific code. This often occurs when a UI (or API) loads a configuration value into a The Enhanced Configuration Scheme codebase does NOT attempt to correct all these instances of caching within UIs or APIs. This would require individual configurations to be tested and any caching mechanisms to be removed. |
FAQs
Can I have different local.cfg files for different environments (e.g. development/testing/staging/production)?
Yes and No. By default, DSpace does NOT allow you to have multiple local.cfg files (one per environment). However, with some minimal tweaks to your configuration scheme, you likely (untested) could achieve this in one of two ways:
Change your
config-definition.xmlto use a system property (of your choice) instead of the hardcoded name "local.cfg". The Configuration Definition file itself does allow for variables to be included, but they must be specified in a previous configuration source (in that config-definition.xml) or via a system property. See the Configuration File Documentation for more details. So, you could simply change your config-definition.xml to use a "dspace.env" system property, and pass "-Ddspace.env=dev" to have it use a[dspace.dir]/config/dev.cfg:Code Block # Change local.cfg to be ${dspace.env} in your config-definition.xml <properties fileName="${dspace.env}.cfg" throwExceptionOnMissing="false" config-name="local" config-optional="true"> ... </properties>Alternatively, you could use the "
include=" setting (of Apache Commons Configuration Properties Files) within your local.cfg file to load a different configuration, again based on a setting specified as a system property. For example, your local.cfg file would ONLY consist of a single "include=" statement, which would load whichever file was specified as the "dspace.env" system property:Code Block # This is the ENTIRE local.cfg (all settings would instead be located in environment-specific config files) # It's whole job is just to load up the configuration for the environment specified by "dspace.env" # For example, -Ddspace.env=dev would load [dspace.dir]/config/dev.cfg # and -Ddspace.env=prod would load [dspace.dir]/config/prod.cfg include = ${dspace.env}.cfg
The option you choose above would likely depend on your own local practices/needs. Either of these options should work, provided that you place your environment-specific configuration files within the [dspace.dir]/config directory alongside the local.cfg file.
Advanced Topics
Configuration Interpolation
...