All Versions
- DSpace 7.x (Current Release)
- DSpace 8.x (Unreleased)
- DSpace 6.x (EOL)
- DSpace 5.x (EOL)
- More Versions...
...
The configuration manager is responsible for reading the main dspace.cfg properties file, managing the 'template' configuration files for other applications such as Apache, and for obtaining the text for e-mail messages.
The system is configured by editing the relevant files in {{\ Wiki Markup [dspace
\]/config
}}, as described in the configuration section.unmigrated-wiki-markup
*When editing configuration files for applications that DSpace uses, such as Apache Tomcat, you may want to edit the copy in {{\[dspace-source
\]
}} and then run {{ant
update
}} or {{ant
overwrite_configs
}} rather than editing the 'live' version directly\!* This will ensure you have a backup copy of your modified configuration files, so that they are not accidentally overwritten in the future.
The ConfigurationManager class can also be invoked as a command line tool:
...
[dspace
\]/bin/dspace
dsprop
property.name
}} This writes the value of _property.name_ from _dspace.cfg_ to the standard output, so that shell scripts can access the DSpace configuration. If the property has no value, nothing is written.This class contains constants that are used to represent types of object and actions in the database. For example, authorization policies can relate to objects of different types, so the resourcepolicy table has columns resource_id, which is the internal ID of the object, and resource_type_id, which indicates whether the object is an item, collection, bitstream etc. The value of resource_type_id is taken from the Constants class, for example Constants.ITEM.
...
Sending e-mails is pretty easy. Just use the configuration manager's getEmail method, set the arguments and recipients, and send.unmigrated-wiki-markup
The e-mail texts are stored in {{\[dspace
\]/config/emails
}}. They are processed by the standard _java.text.MessageFormat_. At the top of each e-mail are listed the appropriate arguments that should be filled out by the sender. Example usage is shown in the _org.dspace.core.Email_ Javadoc API documentation.
The log manager consists of a method that creates a standard log header, and returns it as a string suitable for logging. Note that this class does not actually write anything to the logs; the log header returned should be logged directly by the sender using an appropriate Log4J call, so that information about where the logging is taking place is also stored.
The level of logging can be configured on a per-package or per-class basis by editing {{\ Wiki Markup [dspace
\]/config/log4j.properties
}}. You will need to stop and restart Tomcat for the changes to take effect.
A typical log entry looks like this:
...
Date and time, milliseconds | 2002-11-11 08:11:32,903 |
Level (FATAL, WARN, INFO or DEBUG) | INFO |
Java class | org.dspace.app.webui.servlet.DSpaceServlet |
 | @ |
User email or anonymous | anonymous |
 | : |
Extra log info from context | session_id=BD84E7C194C2CF4BD0EC3A6CAD0142BB |
 | : |
Action | view_item |
 | : |
Extra info | handle=1721.1/1686 |
...
The above format allows the logs to be easily parsed and analyzed. The {{\[dspace
\]/bin/log-reporter
}} script is a simple tool for analyzing logs. Try:
Code Block |
---|
[dspace]/bin/log-reporter --help |
...
There are two ways of configuring named plugins:
...
Code Block |
---|
plugin.named.org.dspace.app.mediafilter.MediaFilter = \ org.dspace.app.mediafilter.JPEGFilter = GIF, JPEG, image/png \ org.dspace.app.mediafilter.TeXFilter = TeX |
Code Block |
---|
plugin.named.org.dspace.app.mediafilter.MediaFilter = \ org.dspace.app.mediafilter.TeXFilter = TeX \ org.dspace.app.mediafilter.PDFFilter = Adobe PDF, PDF, Portable Document Format |
Code Block |
---|
crosswalk.dissemination.stylesheet.DublinCore = xwalk/TESTDIM-2-DC_copy.xsl crosswalk.dissemination.stylesheet.MODS = xwalk/mods.xsl plugin.selfnamed.crosswalk.org.dspace.content.metadata.DisseminationCrosswalk = \ org.dspace.content.metadata.MODSDisseminationCrosswalk, \ org.dspace.content.metadata.XsltDisseminationCrosswalk |
...
The WorkflowManager is invoked by events. While an Item is being submitted, it is held by a WorkspaceItem. Calling the start() method in the WorkflowManager converts a WorkspaceItem to a WorkflowItem, and begins processing the WorkflowItem's state. Since all three steps of the workflow are optional, if no steps are defined, then the Item is simply archived.unmigrated-wiki-markup
Workflows are set per Collection, and steps are defined by creating corresponding entries in the List named workflowGroup. If you wish the workflow to have a step 1, use the administration tools for Collections to create a workflow Group with members who you want to be able to view and approve the Item, and the workflowGroup\[0\] becomes set with the ID of that Group.
If a step is defined in a Collection's workflow, then the WorkflowItem's state is set to that step_POOL. This pooled state is the WorkflowItem waiting for an EPerson in that group to claim the step's task for that WorkflowItem. The WorkflowManager emails the members of that Group notifying them that there is a task to be performed (the text is defined in config/emails,) and when an EPerson goes to their 'My DSpace' page to claim the task, the WorkflowManager is invoked with a claim event, and the WorkflowItem's state advances from STEP_x_POOL to STEP_x (where x is the corresponding step.) The EPerson can also generate an 'unclaim' event, returning the WorkflowItem to the STEP_x_POOL.
...
The org.dspace.administer package contains some classes for administering a DSpace system that are not generally needed by most applications.unmigrated-wiki-markup
The _CreateAdministrator_ class is a simple command-line tool, executed via {{\[dspace
\]/bin/dspace
create-administrator
}}, that creates an administrator e-person with information entered from standard input. This is generally used only once when a DSpace system is initially installed, to create an initial administrator who can then use the Web administration UI to further set up the system. This script does not check for authorization, since it is typically run before there are any e-people to authorize\! Since it must be run as a command-line tool on the server machine, generally this shouldn't cause a problem. A possibility is to have the script only operate when there are no e-people in the system already, though in general, someone with access to command-line scripts on your server is probably in a position to do what they want anyway\!
The DCType class is similar to the org.dspace.content.BitstreamFormat class. It represents an entry in the Dublin Core type registry, that is, a particular element and qualifier, or unqualified element. It is in the administer package because it is only generally required when manipulating the registry itself. Elements and qualifiers are specified as literals in org.dspace.content.Item methods and the org.dspace.content.DCValue class. Only administrators may modify the Dublin Core type registry.
...
Note that since the Handle server runs as a separate JVM to the DSpace Web applications, it uses a separate 'Log4J' configuration, since Log4J does not support multiple JVMs using the same daily rolling logs. This alternative configuration is located at {{\ Wiki Markup [dspace
\]/config/log4j-handle-plugin.properties
}}. The {{\[dspace
\]/bin/start-handle-server
}} script passes in the appropriate command line parameters so that the Handle server uses this configuration.
DSpace's search code is a simple API which currently wraps the Lucene search engine. The first half of the search task is indexing, and org.dspace.search.DSIndexer is the indexing class, which contains indexContent() which if passed an Item, Community, or Collection, will add that content's fields to the index. The methods unIndexContent() and reIndexContent() remove and update content's index information. The DSIndexer class also has a main() method which will rebuild the index completely. This can be invoked by the dspace/bin/index-init (complete rebuild) or dspace/bin/index-update (update) script. The intent was for the main() method to be invoked on a regular basis to avoid index corruption, but we have had no problem with that so far.
...
The browse API contains calls to add and remove items from the index, and to regenerate the indexes from scratch. In general the content management API invokes the necessary browse API calls to keep the browse indexes in sync with what is in the archive, so most applications will not need to invoke those methods.unmigrated-wiki-markup
If the browse index becomes inconsistent for some reason, the _InitializeBrowse_ class is a command line tool (generally invoked using the {{\[dspace
\]/bin/dspace
index-init
}} command) that causes the indexes to be regenerated from scratch.
Presently, the browse API is not tremendously efficient. 'Indexing' takes the form of simply extracting the relevant Dublin Core value, normalizing it (lower-casing and removing any leading article in the case of titles), and inserting that normalized value with the corresponding item ID in the appropriate browse database table. Database views of this table include collection and community IDs for browse operations with a limited scope. When a browse operation is performed, a simple SELECT query is performed, along the lines of:
...