DSpace Service Manager

Introduction

The DSpace Spring Service Manager supports overriding configuration at many levels.

Configuration

Configuring Addons to Support Spring Services

Configuring Addons to support spring happens at two levels, default spring configuration is available int he dspace jar resources or war resources directory and allows the addon developer to inject their configuration into the service manager at load time. The second level is in the deployed dspace.dir config/spring director where configurations can be provided on a addon module by addon module basis.

This latter method requires the addon to implement a SpringLoader to identify the location to look for spring configuration and a place configuration files into that location. This can be seen inside the current [DSDOCDEV:dspace-src]/config/modules/spring.cfg

Configuration Priorities

The ordering of the loading of Spring configuration is the following:

1. configPath = "spring/spring-dspace-applicationContext.xml" relative the current classpath
2. addonResourcePath = "classpath*:spring/spring-dspace-addon-*-services.xml" relative the current classpath
3. coreResourcePath = "classpath*:spring/spring-dspace-core-services.xml" relative the current classpath
4. Finally, an array of SpringLoader API implementations that are checked to verify "config/spring/module" can actually be loaded by its existence on the classpath. The configuration of these SpringLoader API classes can be found in dspace.dir/config/modules/spring.cfg.

Configuring a new Addon

There are 2 ways to create a new spring addon a new spring file can be located in the resources directory or in the configuration dspace.dir/config/spring directory. A spring file can also be located in both of these locations but the configuration directory gets preference and will override any configurations located in the resources directory.

Addon located as resource in jar

In the resources directory of a certain module, a spring file can be added if it matches the following pattern: "spring/spring-dspace-addon-*-services.xml".
An example of this can be found in the dspace-discovery-solr block in the DSpace trunk. (spring-dspace-addon-discovery-services.xml)
Wherever this jar is loaded (JSPUI module, XMLUI module, DSpace command line, ...) the spring files will be processed into services.

Addon located in the dspace.dir/config/spring directory

This directory has the following subdirectories in which spring files can be placed:

• api: when placed in this module the spring files will always be processed into services (since the all the dspace modules are dependent on the api)
• discovery: when placed in this module the spring will only be processed when the discovery library is present (in the case of discovery in the xmlui & in the command line interface).
• jspui: only processed for the jspui
• xmlui: only processed for the xmlui (example: the configurable workflow).

The reason why there is a separate directory is that if a service cannot be loaded, which would the case for the configurable workflow (the jspui would not be able to retrieve the xmlui interface classes), the kernel will crash and DSpace will not start.

Configuring an additional subdirectory for a custom module

So you need to indeed create a new directory in dspace.dir/config/spring. Next you need to create a class that inherits from the "org.dspace.kernel.config.SpringLoader". This class only contains one method named getResourcePaths().
What we do now at the moment is implement this in the following manner:

@Override
public String[] getResourcePaths(ConfigurationService configurationService) {
     StringBuffer filePath = new StringBuffer();
     filePath.append(configurationService.getProperty("dspace.dir"));
     filePath.append(File.separator);
     filePath.append("config");
     filePath.append(File.separator);
     filePath.append("spring");
     filePath.append(File.separator);
     filePath.append("{module.name}"); //Fill in the module name in this string
     filePath.append(File.separator);
     try {

          //By adding the XML_SUFFIX here it doesn't matter if there should be some kind of spring.xml.old file in there it will only load in the active ones.
          return new String[]{new File(filePath.toString()).toURI().toURL().toString() + XML_SUFFIX};
      } catch (MalformedURLException e) {
          return new String[0];
      }
}

After the class has been created you will also need to it add to the "springloader.modules" property located in the dspace.dir/config/modules/spring.cfg.
The spring service manager will check this property to ensure that only the interface implementations which it can find the class for are loaded in.

By doing this way we add some flexibility to the developers so that they can always create their own spring modules & then spring will not crash when it can't find a certain class.

The Core Spring Configuration

Utilizing Autowiring to minimize configuration complexity.

TODO: Outline minimal Spring configuration and autowiring support from Tutorial. DSpace Spring Services Tutorial The TAO of DSpace Services

Accessing via Java codeAccessing the Services Via Service Locator

TODO: Provide docs similar to:

new DSpace().getServiceManager().getServiceByName(....);

Architectural Overview

See Architectural Overview here DSpace Services Framework

Service Manager Startup in Webapplications and CLI

TODO: Outline start process.