This page addresses the most commonly-asked technical questions about DSpace. See also the User FAQ page for anwers to general questions about DSpace. |
Table of Contents
The most recent stable version of DSpace, recommended for production use, is available from GitHub.
To see what's in store for the future, see the DSpace Releases planning page and the DSpace RoadMap
The most recent stable version of DSpace, recommended for production use, is freely available from GitHub.
If you are a developer, DSpace is also available to be checked out using Git/GitHub: https://github.com/DSpace/DSpace See also Development with Git.
You're in the right place. First, you'll want to search this FAQ to see if your question has been asked/answered already. Next, try searching the DSpace System Documentation and the DSpace-Tech mailing list archives.
Still need help? Try our other Support options.
Yes, the DSpace System Documentation includes a section on Installation.
If you run into any problems or have further questions, send an email to the DSpace-Tech mailing list for help, or use one of our other Support options.
If you think you've found a bug, we recommend taking the following steps.
Thanks for being willing to help locate and report bugs! An active community helps us make more stable, bug-free software.
Before putting in a new feature request, you should make sure that the feature would be useful to the broader DSpace community and isn't institutional specific. It's also worth mentioning that since the DSpace developers are all volunteers, you may want to work to locate an interested developer who can help you scope out and begin to develop this new feature.
If you've come up with a new feature idea, we recommend taking the following steps.
Also see How to Contribute to DSpace
See the Troubleshoot an error page for hints on which log files to check for errors, and the recommended way of sending these to the DSpace-Tech Mailing List
From the Documentation, see Storage Layer (which describes the basics for backing up your database and file storage). Also see AIP Backup and Restore, which describes how to backup your DSpace to a set of Archival Information Packages (AIPs).
The official Installation Documentation provides a section on "DSpace over HTTPS" which describes how to configure Apache HTTPD (responding on ports 80 and 443) to redirect to a DSpace running on Apache Tomcat. There are many other guides out on the web for redirecting requests from Apache HTTPD (running on ports 80/443) to Apache Tomcat (usually this redirect is configured via either mod_proxy_ajp or mod_jk). Those guides should also work for DSpace, as DSpace requires no special configurations for Apache HTTPD + Apache Tomcat.
The official Installation Documentation provides a section on "DSpace over HTTPS" which describes enable HTTPS either in Tomcat directly, or in Apache HTTPD (and redirecting requests to Tomcat).
Use the same instructions as the Installation Documentation. DSpace can be installed on any Operating System. For Windows, though you may need to use backslashes (\) in paths instead of forward slashes (/).
See our Troubleshoot an error guide for details
We recommend using Git's merge features to help manage this. See Development with Git for some sample workflows.
Apache Cocoon, the DSpace component XMLUI is based on, keeps a cache of visited pages to speed up access to them. This can pose a problem usually during development of XMLUI themes, when you update XSL, but an older version of the page is served from cache instead of the current version being constructed. It's safe to clear the cache, the only impact it can have is on speed until the cache is repopulated.
In DSpace 1.8.0 and newer, there is a convenient link in XMLUI to clear the cache without restarting the servlet container:
Next to that link, you can also see how many pages are currently cached.
In DSpace versions up to 1.7.2, you have to clear the cache manually by shutting down Tomcat, deleting the cache directory and then restarting Tomcat:
${tomcat6.home}/bin/shutdown.sh |
cd ${tomcat6.home}/work/Catalina/{appropriate.domain.dir}/_/ |
rm -rf cache-dir |
Depending on your Tomcat version, whether you used a package and where you installed it, some common locations of the cache directory are:
/var/cache/tomcat5/work/Catalina/localhost/xmlui/cache-dir /var/lib/tomcat6/work/Catalina/localhost/_/cache-dir /opt/tomcat6/work/Catalina/localhost/xmlui/cache-dir /usr/local/tomcat6/work/Catalina/localhost/xmlui/cache-dir |
You have to remember that access restrictions are inherited from its parent collection only when items are submitted, not when access restrictions are modified. So any new items submitted to that collection will have the collection's restrictions you set, but existing items will keep their current permissions.
In other words: "When a new item gets archived in the repository, it inherits the default policies for an item, defined by the collection in which the item is archived. It's important to realize that these policies can altered for each item, bundle or bitstream, without altering other items or collection properties. Policies are really tied to items, bundles and bitstreams." (source)
So how would you do a mass-change of permissions?
This will remove the search box from the homepage body and keep the search box in the menu:
<xsl:template name="disable_front-page-search" match="dri:div[@id='aspect.discovery.SiteViewer.div.front-page-search']"> </xsl:template> |
If you want items in a particular collection to be rendered differently (add/remove/modify elements) than in the rest of the repository, you can use this recipe.
<xsl:variable name='mycollection'><xsl:value-of select="/dri:document/dri:meta/dri:pageMeta/dri:trail[@target='/handle/123456789/1234']"/></xsl:variable> <xsl:template ...> ... <xsl:if test="$mycollection"> <p>This item belongs to collection 123456789/1234.</p> </xsl:if> ... </xsl:template> |
These are the tables corresponding to individual browse indexes. Browse indexes are defined in dspace.cfg as webui.browse.index.1 through webui.browse.index.n and you can modify which metadata fields you want in the indexes, but you have to remember that after any such change, you need to re-create the indexes.
See ReIndexing Content (for Browse or Search) in the official documentation for your version of DSpace.
See also the relevant dspace.cfg section.
This happens when you skip a step in the instructions for Discovery#EnablingDiscovery. In particular, forgetting to set recent.submissions.count = 0
will mean that recent items continue to be rendered by the Browse aspect in addition to the Discovery aspect, resulting in duplication.
To fix this, set recent.submissions.count = 0
in [dspace]/config/dspace.cfg
and restart your servlet container. If needed, also clear the Cocoon cache: TechnicalFaq#TechnicalFaq-ClearingCocoon(XMLUI)cache
The Messages.properties file is used for translations both in DSpace core ([dspace]/lib/dspace-api-4.0-SNAPSHOT.jar) and in DSpace JSPUI ([dspace]/webapps/jspui/WEB-INF/lib/dspace-api-4.0-SNAPSHOT.jar). You usually want to update the JSPUI one:
From the related email thread:
The issue is related to the Access Rights Awareness feature introduced in Discovery and affect both the search and the browse system (when SolrBrowseDAO are used, optional in 3.x, by default in 4.0).
The issue here is that a single user is included in several groups - that means that the Solr query will include a filter to limit the results to only items that are visible by group1, group2, .... groupN.
Solutions:
in case of exceeding header size:
in case of tooManyClauses Exception:
http://example.com:8080/solr/statistics
) will result in an error (usually status code 403 Unauthorized).server=http://localhost:8080/solr/statistics
in [dspace]/config/modules/solr-statistics.cfg
.solr.url=http://localhost:8080/solr/oai
in [dspace]/config/modules/oai.cfg
andsearch.server=http://localhost:8080/solr/search
in [dspace]/config/modules/discovery.cfg
solr.server=http://localhost:8080/solr
in [dspace-source]/build.properties
Problem: When starting Tomcat, the Tomcat log contains the following error:
Jun 01, 2016 4:41:08 PM org.apache.catalina.core.StandardContext startInternal
SEVERE: Error listenerStart
Explanation: While this may indicate various errors, one possible source of problems is re-using configuration from an older version of DSpace which is incompatible with the new code. Most likely the incompatibility is in [dspace]/config/spring/
.
Solution: Move away your customized configuration directory, start again with the fresh configuration corresponding to the DSpace version you're installing or updating to and then make your changes in that configuration.
Symptom: In a CSV export from Batch Metadata Editing, you can often see that the same column seems to be listed twice, where each of these colums contains values in different rows. The two columns may look like this: dc.title, tc.title[]
Explanation: This is a harmless inconsistency in how DSpace stores metadata. The brackets designate which language the metadata value is in (each metadata field may have multiple values in multiple languages, which is appears in the CSV like this: dc.title, dc.title[de], dc.title[en_US]). In the database, an empty language may have two representations - either an empty string "" or a special NULL value. As DSpace organically developed over time, the programmers of various data ingest methods chose one of these two representations. If you use multiple ingest methods, you may end up with metadata that use both.
Fix 1: In the CSV file, move the values from one of the columns to the other. Then import the CSV file. Upon next export, the empty column won't appear in the CSV file anymore.
Fix 2: Use the following SQL statement to fix the data: UPDATE metadatavalue SET text_lang=NULL WHERE text_lang='';
Any of these fixes will only fix your current data. If you continue to use the two different ingest methods, you'll get new such duplicates.
The permanent fix would have to fix the import methods. The JIRA issue is