Page History

...

The Web UI-related files are located in a variety of directories in the DSpace source tree. Note that as of DSpace version 1.5, the deployment has changed. The build systems has moved to a maven-based system enabling the various projects (JSPUI, XMLUI, etc.) into separate projects. The system still uses the familar 'Ant' to deploy the webapps in later stages.

The Build Process

Wiki MarkupThe DSpace Maven build process constructs a full DSpace installation template directory structure containing a series of web applications. The results are placed in _\[dspace-source\]/dspace/target/dspace-\[version\]-build.dir/_. The process works as follows:

• All the DSpace source code is compiled, and/or automatically downloaded from the Maven Central code/libraries repository.
• Wiki MarkupA full DSpace "installation template" folder is built in {{\[dspace-source\]/dspace/target/dspace-\[version\]-build.dir/}}
  • This DSpace "installation template" folder has a structure identical to the Installed Directory Layout

...

In order to then install & deploy DSpace from this "installation template" folder, you must run the following from {{\[dspace-source\]/dspace/target/dspace-\[version\]-build.dir/}} :

ant -D [dspace]/config/dspace.cfg update

...

The JSPManager.showJSP method uses the standard Java servlet forwarding mechanism is then used to forward the HTTP request to the JSP. The JSP is processed by Tomcat and the results sent back to the user's browser.unmigrated-wiki-markup

There is an exception to this servlet/JSP style: _index.jsp_, the 'home page', receives the HTTP request directly from Tomcat without a servlet being invoked first. This is because in the servlet 2.3 specification, there is no way to map a servlet to handle only requests made to '_/_'; such a mapping results in every request being directed to that servlet. By default, Tomcat forwards requests to '_/_' to _index.jsp_. To try and make things as clean as possible, _index.jsp_ contains some simple code that would normally go in a servlet, and then forwards to _home.jsp_ using the _JSPManager.showJSP_ method. This means localized versions of the 'home page' can be created by placing a customized _home.jsp_ in _\[dspace-source\]/jsp/local_, in the same manner as other JSPs.unmigrated-wiki-markup

_\[dspace-source\]/jsp/dspace-admin/index.jsp_, the administration UI index page, is invoked directly by Tomcat and not through a servlet for similar reasons.

At the top of each JSP file, right after the license and copyright header, is documented the appropriate attributes that a servlet must fill out prior to forwarding to that JSP. No validation is performed; if the servlet does not fill out the necessary attributes, it is likely that an internal server error will occur.

...

Introducing number parameters that should be formatted according to the locale used makes no difference in the message key compared to atring string parameters:

jsp.submit.show-uploaded-file.size-in-bytes = {0} bytes

...

HTML documents must be "self-contained", as explained here. Provided that full path information is known by DSpace, any depth or complexity of HTML document can be served subject to those contraintsconstraints. This is usually possible with some kind of batch import. If, however, the document has been uploaded one file at a time using the Web UI, the path information has been stripped. The system can cope with relative links that refer to a deeper path, e.g.

...

The DSpace platform supports the Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) version 2.0 as a data provider. This is accomplished using the OAICat framework from OCLC.unmigrated-wiki-markup

The DSpace build process builds a Web application archive, _\[dspace-source\]/build/oai.war_), in much the same way as the Web UI build process described above. The only differences are that the JSPs are not included, and _\[dspace-source\]/etc/oai-web.xml_ is used as the deployment descriptor. This 'webapp' is deployed to receive and respond to OAI-PMH requests via HTTP. Note that typically it should _not_ be deployed on SSL (_https:_ protocol). In a typical configuration, this is deployed at _oai_, for example:

http://dspace.myu.edu/oai/request?verb=Identify

...

http://dspace.myu.edu/oai/request

...

It is this URL that should be registered with [www.openarchives.org|http://www. openarchives.org/|www.openarchives.org]. Note that you can easily change the '_request_' portion of the URL by editing _\[dspace-source\]/etc/oai-web.xml_ and rebuilding and deploying _oai.war_.

DSpace provides implementations of the OAICat interfaces AbstractCatalog, RecordFactory and Crosswalk that interface with the DSpace content management API and harvesting API (in the search subsystem).

...

In addition to the implementations of the OAICat interfaces, there is one main configuration file relevant to OAI-PMH support::

• Wiki Markup*oaicat.properties*: This file resides in {{\[dspace\]/config}}. You probably won't need to edit this, as it is pre-configured to meet most needs. You might want to change the {{Identify.earliestDatestamp}} field to more accurately reflect the oldest datestamp in your local DSpace system. (Note that this is the value of the {{last_modified}} column in the {{Item}} database table.)

Sets

OAI-PMH allows repositories to expose an hierarchy of sets in which records may be placed. A record can be in zero or more sets.

...

Introduced in Release 1.6, the DSpace Command Launcher brings together the various command and scripts into a standard-practice for running CLI runtime programs.

Older Versions

...

Prior to Release 1.6, there were various scripts written that masked a more manual approach to running CLI programs. The user had to issue _\[dspace\]/bin/dsrun_ and then java class that ran that program. With release 1.5, scripts were written to mask the _\[dspace\]/bin/dsrun_ command. We have left the java class in the System Administration section since it does have value for debugging purposes and for those who wish to learn about DSpace
programming or wish to customize the code at any time.

Command Launcher Structure

...

Launcher Structure

There are two components to the command launcher: the dspace script and the launcher.xml. The DSpace command calls a java class which in turn refers to _launcher.xml_ that is stored in the _\[dspace\]/config_ directory

launcher.xml is made of several components:

• <command> begins the stanza for a comandcommand
• <name>_name of command_</name> the name of the command that you would use.
• <description>_the description of the command_</description>
• <step> </step> User arguments are parsed and tested.
• <class>_<the java class that is being used to run the CLI program>_</class>
  Prior to release 1.5 if one wanted to regenerate the browse index, one would have to issue the following commands manually: unmigrated-wiki-markup

  Code Block
  [dspace]/bin/dsrun org.dspace.browse.IndexBrowse -f -r [dspace]/bin/dsrun org.dspace.browse.ItemCounter [dspace]/bin/dsrun org.dspace.search.DSIndexer

  In release 1.5 a script was written and in release 1.6 the command _\[dspace\]/bin/dspace index-init_ replaces the script. The stanza from _launcher.xml_ show us how one can build more commands if needed:

  Code Block
  <command> <name>index-update</name> <description>Update the search and browse indexes</description> <step passuserargs="false"> <class>org.dspace.browse.IndexBrowse</class> <argument>-i</argument> </step> <step passuserargs="false"> <class>org.dspace.browse.ItemCounter</class> </step> <step passuserargs="false"> <class>org.dspace.search.DSIndexer</class> </step> </command>

  .