Page History

...

1. Keep each as a separate Maven module
2. Turn each Maven module into a JAR (i.e. update each module's POM)
3. Add a new dependency on Spring Boot (spring-boot-starter-web), to allow each module to use Spring Boot annotations/APIs.
4. Replace each module's web.xml webapp configuration with a Spring @Configuration class (defining several @Beans).  This is a direct replacement for the web.xml concept, and allows you to map the module to a specific path (e.g. /sword or /oai) in Spring Boot..
   1. For example, SWORDWebConfig.java replaces SWORDv1's web.xml
      1. Notice how the class defines a series of @Beans, all of which can be enabled/disabled via DSpace configuration (in this case a "sword-server.enabled" property).
      2. Additionally, this class can pull in other DSpace configuration/settings to allow for path customization (see the "swordPath" variable in this example, which reads from the "sword-server.path" configuration)
5. Remove the Overlay folder for the module (from [dspace-src]/dspace/modules/).  The Maven Overlay concept is only supported by WARs, and therefore, all Overlays would be applied to the Spring Boot webapp.

An example of this can be found in this work-in-progress PR: https://github.com/DSpace/DSpace/pull/22312265

What is the benefit?

There are several known benefits:

• Deploying the DSpace backend is easier, as it's a single web application

...

• within Tomcat
• Arguably, enabling/disabling various "modules" (SWORD, OAI, RDF) is clearer, as it's all based on configuration (and modules you want enabled can be specified in your local.cfg file).
• Server resource usage is minimized, as all modules share the same Java classes/libraries
  • Only one initialization of Hibernate (instead of one per webapp)
  • Only one initialization of Flyway (instead of one per webapp)
• (In the future, post-7.0) We also could consider using Spring Boot's capability to embed Tomcat directly, so that deployment is as simple as running the application.

Other questions to consider

Would I still be able to disable specific features?  For example, what if I don't need or want to install SWORD

Yes, though it'd be different.  Instead of choosing not to install that webapp into Tomcat, you would choose not to build that webapp into DSpaces now a simple configuration.

All of these modules come out-of-the-box within DSpace. You can choose whether to enable or disable specific ones in your local.cfg.

For example, to not install SWORDv1 and SWORDv2, you'd just build DSpace without those modules. As the Spring Boot configuration for each module is provided by a Spring @Configuration class (included in the module), if that module is not included in DSpace then that endpoint/path will not be enabled.

# Build DSpace, excluding the "dspace-sword" and "dspace-swordv2" modules
mvn -U clean package -P '!dspace-sword,!dspace-swordv2'

enabling SWORDv1 in PR#2265 just requires adding this to your local.cfg:

sword-server.enabled = true

Commenting out that setting or setting it to "false" will disable SWORDv1Alternative Option: I'm also looking into a way to provide an "enabled=true" configuration flag in each module's *.cfg file. This flag would allow you to disable the endpoint/path even if the module is included in DSpace.

Can I still overlay specific classes within a module (e.g. in OAI-PMH or SWORD)?

...

Can I still change the URL or path of OAI-PMH or SWORD?

Partially. This is a small compromise.

Obviously, if these modules are included as a separate webapp, you can easily change the paths/URLs to be whatever you want (via Tomcat and/or Apache configurations).

When they are all included in one webapp, then each module must be a subpath of that root webapp.  While this still needs to be tested out further, we should be able to allow you to customize or rename the subpath of each module.  But, you cannot change the base URL.

Yes, it's now a simple configuration.

While each module has a default path, you can easily override it within your local.cfg.

For example, in PR#2265, the SWORDv1 module defaults to using the "sword" path (e.g. http://localhost:8080/spring-rest/sword/).  However, if you wanted to change it to use the "swordv1" path, you can simply set the following in your local.cfg:

sword-server.path = swordv1

Keep in mind that this path will always be a subpath of the root webapp (i.e. spring-rest). So, you need to be careful not to set two modules to use the same subpath (e.g. setting both SWORDv1 and SWORDv2 to use "sword" won't work).  Additionally, the "api" path is reserved, as it's used by the REST API (e.g. http://localhost:8080/spring-rest/api/).

However, if you install the root webapp at the root path, then this behavior is similar to current DSpace (v6). For example, if the "spring-rest" WAR is accessible at For example, if you main URL is https://mydspace.edu/, then all webapps would be a subpath of that:

...

Good question.  Currently, the work-in-progress PR leaves this Spring Boot webapp named "dspace-spring-rest" (i.e. it's the REST API v7 module).  But, if this one webapp now includes all modules, it would need we may want to consider giving it a more generic name to make it clear that it's much more than just the REST API.