Versions Compared

Old Version 3

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 4

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Deploying the DSpace backend is easier, as it's a single web application within Tomcat
  • 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)
  • 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)KEEP IN MIND, this same "module" concept could be extended to DSpace third-party modules.  In this case, all DSpace "modules" are JARs (that optionally use Spring annotations/APIs to add subpaths/behavior) backed by DSpace configuration (which can be used to easily enable/disable/configure the module).  So, installing a new module could be simply dropping in a new JAR (or adding a new dependency) and adding configuration to your local.cfg.
    • (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.
      • However, this would not be available in DSpace 7.0, and would require more discussion on whether it's the right direction for DSpace.

    Other questions to consider

    ...