Status of "dspace/modules/server" for customizations

[David P. Steelman]

Hi,

We have a number of customizations in the "dspace/modules/server" directory, which are used to override classes in the "[dspace-source]/dspace-server-webapp/" as outlined in https://wiki.lyrasis.org/display/DSDOC8x/Advanced+Customisation.

In migrating to DSpace 8.0, we have encountered the issue described in https://github.com/DSpace/DSpace/issues/9987, in which the customizations in the "dspace/modules/server" directory are not present when running via the "server-boot" embedded Tomcat server. Included in that issue is Tim Donohue's comment (https://github.com/DSpace/DSpace/issues/9987#issuecomment-2470793652) that includes:

 We may need to simply document that server is unsupported, if there's no way to reference it from server-boot.

At the moment, we've worked around this issue by using a configuration similar to that in DSpace 7.6.2, only using Apache Tomcat v10.1, instead of v9.

So just wondering about the status of using "dspace/modules/server" for customizations. Is this something that we should still be using? Is there an alternate recommended method for keeping local customizations separate from stock DSpace code?

Thanks,

David

[DSpace Technical Support]

Hi David,

At this point in time, that ticket is unclaimed: https://github.com/DSpace/DSpace/issues/9987    DSpace is fully built/supported by volunteers (we have no central development team to assign tickets to).  So, this ticket is waiting on someone in the community to help us dig into the code to see if there's a way to support this in the "server-boot" installation approach.

So, unfortunately, at this time, we don't have an answer to your question until someone can help us to investigate if there's a solution to this problem.

In the meantime, the only approaches I can suggest are to *not use* "server-boot" (i.e. move back to installing Tomcat manually, as it sounds like you are doing), or consider moving your code directly into the "dspace-api" or "dspace-server-webapp" modules (which is less ideal, I know, because your code is no longer separated)

Once someone has claimed that ticket we should know more.  If anyone is watching this thread and is interested in helping out, please feel free to claim the ticket (by simply adding comment to the ticket letting us know you are investigating it)

Tim

[David P. Steelman]

Tim,

Thanks for the response.

Two questions, to help inform our response to this issue:

1) Was there a particular reason DSpace moved to using an "embedded Tomcat" server configuration?

2) Would a pull request removing the "embedded Tomcat" server configuration and restoring things as they were in DSpace 7.6.2 be accepted as a "fix" for Issue 9987?

Thanks,

David

--
All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dspace-tech/197cb9d3-eb5c-4ebd-97b0-45269f3f4446n%40googlegroups.com.

[DSpace Technical Support]

Hi David,

The embedded Tomcat option is just a *new option* for installation. It was added because it can provide an easier installation for sites that wish to use it.  However, it is *not* required to use in DSpace 8.x.

In DSpace 8.x, you can still install DSpace in the same way as you did in 7.6.2.  That is the option documented in the Installation Guide where you install Tomcat manually, and deploy the "server" app in the same way you did in 7.6.2.  See step 12 "Deploy web application" at https://wiki.lyrasis.org/display/DSDOC8x/Installing+DSpace#InstallingDSpace-BackendInstallation  It lists two options, the "traditional installation" (which is the same as 7.6.2) or the new "Runnable JAR" (which is the new "server-boot")

So, there's no reason to remove embedded Tomcat in order to restore 7.6.2 behavior.  You have the choice of two deployment options in 8.x.

I hope that helps to clarify things!

Tim