The form is:

webui.browse.index.<n> = <index name> : \
                               <schema
	prefix>.<element>[.<qualifier>|.*] : \
                               (date | title | text) : \
                               (full | single) \

If you are customising this list beyond the default you will need to insert the text you wish to appear in the navigation and on link and buttons describing the browse index into the Messages.properties file. The system uses parameters of the form:

browse.type.<index name>

The Index numbers denoted by <n> must start from 1 and increment by 1 continuously thereafter. Deviation from this rule will cause an error during installation or during configuration update

This is an example configuration, as it appears by default in dspace.cfg.

webui.browse.index.1 = dateissued:dc.date.issued:date:full
webui.browse.index.2 = author:dc.contributor.*:text:single
webui.browse.index.3 = title:dc.title:title:full
webui.browse.index.4 = subject:dc.subject.*:text:single
webui.browse.index.5 = dateaccessioned:dc.date.accessioned:date:full

Sort options will be available when browsing a list of items (i.e. only in "full" mode, not "single" mode). You can define an arbitrary number of fields to sort on, irrespective of which fields you display using webui.itemlist.columns

The format is:

webui.browse.sort-option.<n> = <option name> : \
                               <schema
	prefix>.<element>[.<qualifier>|.*] : \
                               (date | text)

This is the example configuration as it appears in the default dspace.cfg:

                           
webui.browse.sort-option.1 = title:dc.title:text
webui.browse.sort-option.2 = date:dc.date.issued:date

(Note: this section actually applies to any field with multiple values, but authors are the defined case)

You can define which field is the author (or editor, or other repeated field) which this configuration will deal with thus:

webui.browse.author-field = dc.contributor.*

Replace dc.contributor.* with another field if appropriate. The field should be listed in the configuration for webui.itemlist.columns, otherwise you will not see its effect. It must also be defined in webui.itemlist.columns as being of data type text, otherwise the functionality will be overriden by the specific data type features.

Now that we know which field is our author or other multiple metadata value field we can provide the option to truncate the number of values displayed by default. We replace the remaining list of values with "et al" or the language pack specific alternative. Note that this is just for the default, and users will have the option of changing the number displayed when they browse the results

webui.browse.author-limit = <n>

Where <n> is an integer number of values to be displayed. Use -1 for unlimited (default).

We can define which fields link to other browse listings. This is useful, for example, to link an author's name to a list of just that author's items. The effect this has is to create links to browse views for the item clicked on. If it is a "single" type, it will link to a view of all the items which share that metadata element in common (i.e. all the papers by a single author). If it is a "full" type, it will link to a view of the standard full browse page, starting with the value of the link clicked on.

The form is:

webui.browse.link.<n> = <index name>:<display column
	metadata>

This should associated the name of one of the browse indices (webui.browse.index.n) with a metadata field listed in webui.itemlist.columns above. If this condition is not fulfilled, cross-linking will not work. Note also that cross-linking only works for metadata fields not tagged as title in webui.itemlist.columns.

The following example shows the default in dspace.cfg which links author names to lists of their publications:

webui.browse.link.1 = author:dc.contributor.*

This allows us to define which index to base Recent Submission display on, and how many we should show at any one time. This uses the PluginManager to automatically load the relevant plugin for the Community and Collection home pages. Values given in examples are the defaults supplied in dspace.cfg

First define the sort name (from webui.browse.sort-option) to use for # displaying recent submissions. For example:

recent.submissions.sort-option = dateaccessioned

Define how many recent submissions should be displayed at any one time, for example:

recent.submissions.count = 5

Now we need to set up the processors that the PluginManager will load to actually perform the recent submissions query on the relevant pages.

Tell the community and collection pages that we are using the Recent Submissions code

plugin.sequence.org.dspace.plugin.CommunityHomeProcessor = \
        org.dspace.app.webui.components.RecentCommunitySubmissions

plugin.sequence.org.dspace.plugin.CollectionHomeProcessor = \
        org.dspace.app.webui.components.RecentCollectionSubmissions

This is already configured by default in dspace.cfg so there should be no need for you to worry about it

Because the item mapper requires a primitive implementation of the browse system to be present, we simply need to tell that system which of our indices defines the author browse (or equivalent) so that the mapper can list authors' items for mapping

Define the the index name (from webui.browse.index) to use for displaying items by author

itemmap.author.index = author

So if you change the name of your author browse field, you will also need to update this configuration.

The <aspects> section defines the "Aspect Chain", or the linear set of aspects that are installed in the repository. For each aspect that is installed in the repository, the aspect makes available new features to the interface. For example, if the "submission" aspect were to be commented out or removed from the xmlui.xconf, then users would not be able to submit new items into the repository (even the links and language prompting users to submit items are removed). Each <aspect> element has two attributes, name & path. The name is used to identify the Aspect, while the path determines the directory where the aspect's code is located. Here is the default aspect configuration:

   <aspects>
     <aspect name="Artifact Browser"
	path="resource://aspects/ArtifactBrowser/" />
     <aspect name="Administration"
	path="resource://aspects/Administrative/" />
     <aspect name="E-Person" path="resource://aspects/EPerson/"
	/>
     <aspect name="Submission and Workflow"
	path="resource://aspects/Submission/" />
   </aspects>

A standard distribution of Manakin/DSpace includes four "core" aspects:

The <themes> section defines a set of "rules" that determine where themes are installed in the repository. Each rule is processed in the order that it appears, and the first rule that matches determines the theme that is applied (so order is important). Each rule consists of a <theme> element with several possible attributes:

If you use the "handle" attribute, the effect is cascading, meaning if a rule is established for a community then all collections and items within that community will also have this theme apply to them as well. Here is an example configuration:

  <themes>
    <theme name="Theme 1" handle="123456789/23"
	path="theme1/"/>
    <theme name="Theme 2" regex="community-list"
	path="theme2/"/>
    <theme name="Reference Theme" regex=".*"
	path="Reference/"/>
  </themes>

In the example above three themes are configured: "Theme 1", "Theme 2", and the "Reference Theme". The first rule specifies that "Theme 1" will apply to all communities, collections, or items that are contained under the parent community "123456789/23". The next rule specifies any URL containing the string "community-list" will get "Theme 2". The final rule, using the regular expression ".*", will match anything, so all pages which have not matched one of the preceding rules will be matched to the Reference Theme.

The default language for the application is set via the [dspace-source]/config/dspace.cfg parameter default.locale.

This is a locale according to i18n and might consist of country, country_language or country_language_variant,

e. g.: default.locale=en. If not default locale is specified the server locale will be used instead.

Execution mode can be configured using command line options. Information on the options can be found at any time by running [dspace]/bin/checker --help. The different modes are described below; see the "Which to use" section that follows for details on the various pros and cons.

Unless a particular bitstream or handle is specified, the Checksum Checker will always check bitstreams in order of the least recently checked bitstream. (Note that this means that the most recently ingested bitstreams will be the last ones checked by the Checksum Checker.)

To check a specific number of bitstreams, use the -c option followed by an integer number of bitstreams to check:

bin/checker -c 10

Limited count mode is particularly useful for checking that the checker is executing properly. The Checksum Checker's default execution mode is to check a single bitstream, as if the -c 1 option had been given.

To run the Checker for a specific period of time, use the -d option with a time argument:

bin/checker -d 10m
bin/checker -d 2h

Valid options for specifying duration are s for seconds, m for minutes, h for hours, d for days, w for weeks, and y for years (OK, so we're optimists).

The checker will keep starting new bitstream checks for the specified duration, so actual execution duration will be slightly longer than the specified duration. Bear this in mind when scheduling checks.

To check one or more particular bitstreams by ID, use the -b option followed by one or more bitstream IDs:

bin/checker -b 1 2 3 4

This mode is useful when analyzing problems reported in the logs and when verifying that a resolution has been successful.

Use the -a option followed by a handle:

bin/checker -a 123456/123

This will check all the bitstreams inside an item, collection or community.

There are two looping modes:

bin/checker -l     # Loops once through the repository  
bin/checker -L      # Loops continuously through the repository

The -l option can be used if your repository is relatively small and your backup strategy requires it to be completely validated at a particular point. The -L option might be useful if you have a large repository, and you don't mind (or can avoid) the IO load caused by the checker.

The Checksum Checker was designed with the idea that most sys admins will run it from the cron. For small repositories we recommend using the -l option in the cron. For larger repositories that cannot be completely checked in a couple of hours, we recommend the -d option in the cron.

Checksum Checker uses log4j to report its results. By default it will report to a log called [dspace]/log/checker.log, and it will report only on bitstreams for which the newly calculated checksum does not match the stored checksum. To report on all bitstreams checked regardless of outcome, use the -v (verbose) command line option:

bin/checker -l -v    #Loop through the repository once and
  report in detail about every bitstream checked.

To change the location of the log, or to modify the prefix used on each line of output, edit the [dspace]/config/templates/log4j.properties file and run [dspace]/bin/install_configs.

The Checksum Checker will store the result of every check in the checksum_history table. By default, successful checksum matches that are eight weeks old or older will be deleted when the -p command line option is used (unsuccessful ones will be retained indefinitely). The amount of time for which results are retained in the checksum_history table can be modified by one of two methods:

Pruning is controlled by a number of properties, each of which describes a checksum result code, and the length of time for which results with that code should be retained. The format is checker.retention.[RESULT CODE]=[duration]. For example: -

checker.retention.CHECKSUM_MATCH=8w

indicates that successful checksum matches will be retained for eight weeks. Supported units of time are

(Note that these units are also used for describing durations for the -d limited duration mode.)

There is a special property, checker.retention.default, that is used to assign a default retention period.

To execute the pruning you must use the -p command line option (with or without a properties file). Checksum Checker will prune the history table before beginning new checks. We recommend that you use this option regularly, as the checksum_history table can grow very large without it.

The default method org.dspace.authenticate.PasswordAuthentication has the following properties:

The X.509 authentication method uses an X.509 certificate sent by the client to establish his/her identity. It requires the client to have a personal Web certificate installed on their browser (or other client software) which is issued by a Certifying Authority (CA) recognized by the web server.

Also included in the source is an implementation of an authentication method used at MIT, edu.mit.dspace.MITSpecialGroup. This does not actually authenticate a user, it only adds the current user to a special (dynamic) group called 'MIT Users' (which must be present in the system!). This allows us to create authorization policies for MIT users without having to manually maintain membership of the MIT users group.

By keeping this code in a separate method, we can customize the authentication process for MIT by simply adding it to the stack in the DSpace configuration. None of the code has to be touched.

You can create your own custom authentication method and add it to the stack. Use the most similar existing method as a model, e.g. org.dspace.authenticate.PasswordAuthentication for an "explicit" method (with credentials entered interactively) or org.dspace.authenticate.X509Authentication for an implicit method.

You can enable IP authentication by adding its method to the stack in the DSpace configuration, e.g.:

plugin.sequence.org.dspace.authenticate.AuthenticationMethod =
	org.dspace.authenticate.IPAuthentication

You are than able to map DSpace groups to IP's in dspace.cfg by setting authentication.ip.GROUPNAME = iprange[, iprange ...], e.g:

  authentication.ip.MY_UNIVERSITY = 10.1.2.3, \            # Full IP
                                    13.5, \                # Partial
	IP
                                    11.3.4.5/24, \         # with
	CIDR
                                    12.7.8.9/255.255.128.0 # with
	netmask
 

Note: if the Groupname contains blanks you must escape the, e.g. Department\ of\ Statistics

You can enable LDAP authentication by adding its method to the stack in the DSpace configuration, e.g.

plugin.sequence.org.dspace.authenticate.AuthenticationMethod =
	org.dspace.authenticate.LDAPAuthentication

If LDAP is enabled in the dspace.cfg file, then new users will be able to register by entering their username and password without being sent the registration token. If users do not have a username and password, then they can still register and login with just their email address the same way they do now.

If you want to give any special privileges to LDAP users, create a stackable authentication method to automatically put people who have a netid into a special group. You might also want to give certain email addresses special privileges. Refer to the Custom Authentication Code section above for more information about how to do this.

Here is an explanation of what each of the different configuration parameters are for:

Configuration for the statistics system are in [dspace]/config/dstat.cfg and the file should guide you to correctly filling in the details required. For the most part you will not need to change this file. You may wish to edit start.year and start.month to customize the start date of the statistics.

The following scripts must be run (in this order) generate the statistcis:

stat-initial
stat-general
stat-monthly
stat-report-initial
stat-report-general
stat-report-monthly

Scripts eding with -general do the work for building reports spanning the entire history of the archive; scripts ending -initial are to initialise the reports by doing monthly reports from some start date up to the present; scripts ending -monthly generate a single monthly report for the current month.

stat-inital and stat-report-inital must be run to generate the first set of statistics. Following that, stat-monthly, stat-general, stat-report-monthly and stat-report-general should be run daily to update the statistics reports.

If you want additional customisations, you can find additional information about the scripts by running:

[dspace]/bin/dsrun org.dspace.app.statistics.LogAnalyser -help
[dspace]/bin/dsrun org.dspace.app.statistics.ReportGenerator -help

By activating the DIDL provider, DSpace items are represented as MPEG-21 DIDL objects. These DIDL objects are XML documents that wrap both the Dublin Core metadata that describes the DSpace item and its actual bitstreams. A bitstream is provided inline in the DIDL object in a base64 encoded manner, and/or by means of a pointer to the bitstream. The data provider exposes DIDL objects via the metadataPrefix didl.

The crosswalk does not deal with special characters and purposely skips dissemination of the license.txt file awaiting a better understanding on how to map DSpace rights information to MPEG21-DIDL.

The DIDL Crosswalk can be activated as follows:

The MODS crosswalk is a self-named plugin. To configure an instance of the MODS crosswalk, add a property to the DSpace configuration starting with "crosswalk.mods.properties."; the final word of the property name becomes the plugin's name. For example, a property name crosswalk.mods.properties.MODS defines a crosswalk plugin named "MODS".

The value of this property is a path to a separate properties file containing the configuration for this crosswalk. The pathname is relative to the DSpace configuration directory, i.e. the config subdirectory of the DSpace install directory. So, a line like:

 crosswalk.mods.properties.MODS = crosswalks/mods.properties

defines a crosswalk named MODS whose configuration comes from the file [dspace]/config/crosswalks/mods.properties.

The MODS crosswalk properties file is a list of properties describing how DSpace metadata elements are to be turned into elements of the MODS XML output document. The property name is a concatenation of the metadata schema, element name, and optionally the qualifier. For example, the contributor.author element in the native Dublin Core schema would be: dc.contributor.author. The value of the property is a line containing two segments separated by the vertical bar ("|"): The first part is an XML fragment which is copied into the output document. The second is an XPath expression describing where in that fragment to put the value of the metadata element. For example, in this property:

dc.contributor.author = <mods:name><mods:role><mods:roleTerm
	type="text">author</mods:roleTerm></mods:role><mods:namePart>%s</mods:
;<mods:namePart>%s</mods:namePart></mods:name> |
	mods:namePart/text()

Some of the examples include the string "%s" in the prototype XML where the text value is to be inserted, but don't pay any attention to it, it is an artifact that the crosswalk ignores. For example, given an author named Jack Florey, the crosswalk will insert

             <mods:name> <mods:role> <mods:roleTerm
	type="text">author</mods:roleTerm> </mods:role>
	<mods:namePart>
             Jack Florey
             </mods:namePart>
	</mods:name>

          

into the output document. Read the example configuration file for more details.

The QDC crosswalk is a self-named plugin. To configure an instance of the QDC crosswalk, add a property to the DSpace configuration starting with "crosswalk.qdc.properties."; the final word of the property name becomes the plugin's name. For example, a property name crosswalk.qdc.properties.QDC defines a crosswalk plugin named "QDC".

The value of this property is a path to a separate properties file containing the configuration for this crosswalk. The pathname is relative to the DSpace configuration directory, i.e. the config subdirectory of the DSpace install directory. So, a line like:

  crosswalk.qdc.properties.QDC = crosswalks/qdc.properties

defines a crosswalk named QDC whose configuration comes from the file [dspace]/config/crosswalks/qdc.properties.

You'll also need to configure the namespaces and schema location strings for the XML output generated by this crosswalk. The namespaces property names are of the format:

crosswalk.qdc.namespace.prefix = uri

where prefix is the namespace prefix and uri is the namespace URI.

For example, this shows how a crosswalk named "QDC" would be configured:

crosswalk.qdc.properties.QDC = crosswalks/QDC.properties
crosswalk.qdc.namespace.QDC.dc = http://purl.org/dc/elements/1.1/
crosswalk.qdc.namespace.QDC.dcterms = http://purl.org/dc/terms/
crosswalk.qdc.schemaLocation.QDC  = \
  http://purl.org/dc/terms/
	http://dublincore.org/schemas/xmls/qdc/2003/04/02/qualifieddc.xsd

The QDC crosswalk properties file is a list of properties describing how DSpace metadata elements are to be turned into elements of the Qualified DC XML output document. The property name is a concatenation of the metadata schema, element name, and optionally the qualifier. For example, the contributor.author element in the native Dublin Core schema would be: dc.contributor.author. The value of the property is an XML fragment, the element whose value will be set to the value of the metadata field in the property key.

For example, in this property:

  dc.coverage.temporal = <dcterms:temporal />

the generated XML in the output document would look like, e.g.:

  <dcterms:temporal>Fall, 2005</dcterms:temporal>

The XSLT crosswalks use XSL stylesheet transformation (XSLT) to transform an XML-based external metadata format to or from DSpace's internal metadata. XSLT crosswalks are much more powerful and flexible than the configurable MODS and QDC crosswalks, but they demand some esoteric knowledge (XSL stylesheets). Given that, you can create all the crosswalks you need just by adding stylesheets and configuration lines, without touching any of the Java code.

A submission crosswalk is described by a configuration key starting with 'crosswalk.submission.", like

  crosswalk.submission. PluginName.stylesheet = 
	path

The PluginName is, of course, the plugin's name. The path value is the path to the file containing the crosswalk stylesheet (relative to dspace.dir/config).

Here is an example that configures a crosswalk named "LOM" using a stylesheet in [dspace]/config/crosswalks/d-lom.xsl:

  crosswalk.submission.stylesheet.LOM = crosswalks/d-lom.xsl

A dissemination crosswalk is described by a configuration key starting with 'crosswalk.dissemination.", like

  crosswalk.dissemination. PluginName.stylesheet = 
	path

The PluginName is, of course, the plugin's name. The path value is the path to the file containing the crosswalk stylesheet (relative to dspace.dir/config).

You can make two different plugin names point to the same crosswalk, by adding two configuration entries with the same path, e.g.

    crosswalk.submission.MyFormat.stylesheet =
	crosswalks/myformat.xslt
    crosswalk.submission.almost_DC.stylesheet =
	crosswalks/myformat.xslt

The dissemination crosswalk must also be configured with an XML Namespace (including prefix and URI) and an XML Schema for its output format. This is configured on additional properties in the DSpace Configuration, i.e.:

   crosswalk.dissemination. PluginName.namespace. Prefix = 
	namespace-URI
   crosswalk.dissemination. PluginName.schemaLocation = 
	schemaLocation value

For example:

   crosswalk.dissemination.qdc.namespace.dc =
	http://purl.org/dc/elements/1.1/
   crosswalk.dissemination.qdc.namespace.dcterms =
	http://purl.org/dc/terms/
   crosswalk.dissemination.qdc.schemaLocation = \
      http://purl.org/dc/elements/1.1/
	http://dublincore.org/schemas/xmls/qdc/2003/04/02/qualifieddc.xsd

XSLT crosswalk plugins translate between the external metadata format and an XML format called DSpace Intermediate Metadata, which exists only for the purpose of XSLT crosswalks. It is never to be exported from DSpace, since it is not an acknowledged metadata format, it is simply an expression of the way DSpace stores its metadata fields internally. All the elements in a DIM document are in the namespace http://www.dspace.org/xmlns/dspace/dim.

The root element is named dim. It has zero or more children, all field elements. It may have an attribute dspaceType, which identifies the type of object ("ITEM", "COLLECTION", or "COMMUNITY") this metadata describes. This attribute is only guaranteed to be set for dissemination crosswalks.

Each field element may have the following attributes:

The value of field is the value of that metadata field. Fields with the same qualifiers may be repeated. Here is an example of the DIM format:

    <dim:dim xmlns:dim="http://www.dspace.org/xmlns/dspace/dim"
	dspaceType="ITEM">
      <dim:field mdschema="dc" element="title"
	lang="en_US">
        The Endochronic Properties of Resublimated Thiotimonline
      </dim:field>
      <dim:field mdschema="dc" element="contributor"
	qualifier="author">
        Isaac Asimov
      </dim:field>
      <dim:field mdschema="dc" element="language"
	qualifier="iso">
        eng
      </dim:field>
      <dim:field mdschema="dc" element="subject" qualifier="other"
	lang="en_US">
        time-travel scifi hoax
      </dim:field>
      <dim:field element="publisher">
        Boston University Department of Biochemistry
      </dim:field>
    </dim:dim>

The XSLT crosswalks will automatically reload an XSL stylesheet that has been modified, so you can edit and test stylesheets without restarting DSpace. You can test a dissemination crosswalk by hooking it up to an OAI-PMH crosswalk and using an OAI request to get the metadata for a known item.

Testing the submission crosswalk is more difficult, so we have supplied a command-line utility to help. It calls the crosswalk plugin to translate an XML document you submit, and displays the resulting intermediate XML (DIM). Invoke it with:

 [dspace]/bin/dsrun
	org.dspace.content.crosswalk.XSLTIngestionCrosswalk [-l]  plugin
	input-file

..where plugin is the name of the crosswalk plugin to test (e.g. "LOM"), and input-file is a file containing an XML document of metadata in the appropriate format.

Add the -l option to to pass the ingestion crosswalk a list of elements instead of a whole document, as if the List form of the ingest() method had been called. This is needed to test ingesters for formats like DC that get called with lists of elements instead of a root element.

There is probably a very complicated way to do this correctly by adding new Maven modules and POMs and things, but here is what I did, being in a hurry and just wanting immediate results (and not caring about maintaining a DSpace installation, upgrading, etc):

First, you need to download the XPDF suite and install it on your server, e.g. under /usr/local/bin.

The only tools you really need are:

New Media Filters must implement the org.dspace.app.mediafilter.FormatFilter interface. More information on the methods you need to implement is provided in the FormatFilter.java source file. For example:

             public class MySimpleMediaFilter implements
	FormatFilter

          

Alternatively, you could extend the org.dspace.app.mediafilter.MediaFilter class, which just defaults to performing no pre/post-processing of bitstreams before or after filtering.

             public class MySimpleMediaFilter extends
	MediaFilter

          

You must give your new filter a "name", by adding it and its name to the plugin.named.org.dspace.app.mediafilter.FormatFilter field in dspace.cfg. In addition to naming your filter, make sure to specify its input formats in the filter.<class path>.inputFormats config item. Note the input formats must match the short description field in the Bitstream Format Registry (i.e. bitstreamformatregistry table).

             plugin.named.org.dspace.app.mediafilter.FormatFilter = \
	org.dspace.app.mediafilter.MySimpleMediaFilter = My Simple Text
	Filter, \ ...
	filter.org.dspace.app.mediafilter.MySimpleMediaFilter.inputFormats =
	Text

          

WARNING: If you neglect to define the inputFormats for a particular filter, the MediaFilterManager will never call that filter, since it will never find a bitstream which has a format matching that filter's input format(s).

If you have a complex Media Filter class, which actually performs different filtering for different formats (e.g. conversion from Word to PDF and conversion from Excel to CSV), you should define this as a Dynamic / Self-Named Format Filter.

If you have a more complex Media/Format Filter, which actually performs multiple filtering or conversions for different formats (e.g. conversion from Word to PDF and conversion from Excel to CSV), you should have define a class which implements the FormatFilter interface, while also extending the SelfNamedPlugin class. For example:

             public class MyComplexMediaFilter extends
	SelfNamedPlugin implements FormatFilter

          

Since SelfNamedPlugins are self-named (as stated), they must provide the various names the plugin uses by defining a getPluginNames() method. Generally speaking, each "name" the plugin uses should correspond to a different type of filter it implements (e.g. "Word2PDF" and "Excel2CSV" are two good names for a complex media filter which performs both Word to PDF and Excel to CSV conversions).

Self-Named Media/Format Filters are also configured differently in dspace.cfg. Below is a general template for a Self Named Filter (defined by an imaginary MyComplexMediaFilter class, which can perform both Word to PDF and Excel to CSV conversions):

             #Add to a list of all Self Named filters
	plugin.selfnamed.org.dspace.app.mediafilter.FormatFilter = \
	org.dspace.app.mediafilter.MyComplexMediaFilter #Define input formats
	for each "named" plugin this filter implements
	filter.org.dspace.app.mediafilter.MyComplexMediaFilter.Word2PDF.inputF
ormats = Microsoft Word
	filter.org.dspace.app.mediafilter.MyComplexMediaFilter.Excel2CSV.input
Formats = Microsoft Excel

          

As shown above, each Self-Named Filter class must be listed in the plugin.selfnamed.org.dspace.app.mediafilter.FormatFilter item in dspace.cfg. In addition, each Self-Named Filter must define the input formats for each named plugin defined by that filter. In the above example the MyComplexMediaFilter class is assumed to have defined two named plugins, Word2PDF and Excel2CSV. So, these two valid plugin names ("Word2PDF" and "Excel2CSV") must be returned by the getPluginNames() method of the MyComplexMediaFilter class.

These named plugins take different input formats as defined above (see the corresponding inputFormats setting). WARNING: If you neglect to define the inputFormats for a particular named plugin, the MediaFilterManager will never call that plugin, since it will never find a bitstream which has a format matching that plugin's input format(s).

For a particular Self-Named Filter, you are also welcome to define additional configuration settings in dspace.cfg. To continue with our current example, each of our imaginary plugins actually results in a different output format (Word2PDF creates "Adobe PDF", while Excel2CSV creates "Comma Separated Values"). To allow this complex Media Filter to be even more configurable (especially across institutions, with potential different "Bitstream Format Registries"), you may wish to allow for the output format to be customizable for each named plugin. For example:

             #Define output formats for each named plugin
	filter.org.dspace.app.mediafilter.MyComplexMediaFilter.Word2PDF.output
Format = Adobe PDF
	filter.org.dspace.app.mediafilter.MyComplexMediaFilter.Excel2CSV.outpu
tFormat = Comma Separated Values

          

Any custom configuration fields in dspace.cfg defined by your filter are ignored by the MediaFilterManager, so it is up to your custom media filter class to read those configurations and apply them as necessary. For example, you could use the following sample Java code in your MyComplexMediaFilter class to read these custom outputFormat configurations from dspace.cfg :

             //get "outputFormat" configuration from dspace.cfg
	String outputFormat =
	ConfigurationManager.getProperty(MediaFilterManager.FILTER_PREFIX +
	"." + MyComplexMediaFilter.class.getName() + "." +
	this.getPluginInstanceName() + ".outputFormat");

          

The Passive plugin is provided as the class org.dspace.app.statistics.PassiveUsageEvent. It absorbs events without effect. Use the Passive plugin when you have no use for usage event postings. This is the default if no plugin is configured.

The Tab File Logger plugin is provided as the class org.dspace.app.statistics.UsageEventTabFileLogger. It writes event records to a file in tab-separated column format. If left unconfigured, an error will be noted in the DSpace log and no file will be produced. To specify the file path, provide an absolute path as the value for usageEvent.tabFileLogger.file in dspace.cfg.

The XML Logger plugin is provided as the class org.dspace.app.statistics.UsageEventXMLLogger. It writes event records to a file in a simple XML-like format. If left unconfigured, an error will be noted in the DSpace log and no file will be produced. To specify the file path, provide an absolute path as the value for usageEvent.xmlLogger.file in dspace.cfg.