This page describes a brainstorm / work in progress. It is not stable or usable in Production at this time. If this is ever released, you'll hear about it in a future release! |
In the past we've had several discussions/attempts at making DSpace easier to install (e.g. Installer Prototype, Installer Brainstorms).
However, with DSpace 7.0, the new REST API (dspace-spring-rest module) is now a Spring Boot web application. Spring Boot's entire purpose is to provide tools to make easy-to-install web applications.
This proposal is to begin to utilize the tools in Spring Boot to turn DSpace's "backend" webapps (REST API, OAI-PMH, SWORD, RDF) into a single, easy to install webapp. At this time, I'm concentrating only on the backend webapps, as they are all Java webapps. So, it does not include the new Angular UI. I'm also specifically excluding the old REST API (v4-6), as it is deprecated in DSpace 7 (and will be removed in DSpace 8).
All of the separate, backend web applications (namely SWORDv1, SWORDv2, OAI-PMH, and RDF) would be merged into a single Spring Boot web application (i.e. the REST API v7 webapp). This can be achieved as follows:
web.xml
webapp configuration with a Spring @Configuration
class (defining several @Beans). This is a direct replacement for the web.xml concept.[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/2265
There are several known benefits:
Yes, it's 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, 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 SWORDv1.
While this still needs to be tested out further, you should be able to simply move those overlays to overlay the main DSpace Spring Boot web application. So, overlays should still be possible, but they would all now exist in a single place (i.e. you'd always be overlaying the "dspace-spring-rest" webapp, as that's the webapp that loads all other modules)
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 https://mydspace.edu/
, then all webapps would be a subpath of that:
https://mydspace.edu/api/ (REST API v7)
https://mydspace.edu/sword/ (SWORDv1)
https://mydspace.edu/oai/ (OAI-PMH)
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, 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.