Skip to content

DRYD-2233: Update Resteasy Configuration - #583

Open
mikejritter wants to merge 3 commits into
collectionspace:developfrom
mikejritter:bugfix/dryd-2233-resteasy-deployment
Open

mikejritter wants to merge 3 commits into
collectionspace:developfrom
mikejritter:bugfix/dryd-2233-resteasy-deployment

Conversation

@mikejritter

Copy link
Copy Markdown
Contributor

What does this do?
This updates our Resteasy deployment configuration so that we only instantiate our Application class a single time:

  • Add resteasy-servlet-initializer dependency
  • Prefer javax.ws.rs.core.Application as a deployment strategy
  • Change CSpaceResteasyBootstrap from extending ResteasyBootstrap to implementing Feature

Why are we doing this? (with JIRA link)
Jira: https://collectionspace.atlassian.net/browse/DRYD-2233

Using multiple deployment strategies causes the application to misbehave in subtle ways. So far it hasn't impacted runtime, but when adding Micrometer it was causing an exception to occur when scraping the metric registry.

The preference toward the servlet initializer and javax.ws.rs.core.Application comes from looking at the resteasy documentation, as it frequently mentions This section is pretty much deprecated if you are using a Servlet 3.0 container or higher. For running the CSpaceResteasyBoostrap post-init tasks, multiple ways of running were tried (e.g. as a ServletContextListener), but the requirement of having the ResteasyDeployment object available (and as such, the CollectionSpaceJaxRsApplication) meant that options were limited. The result of this was using a Feature even though it does not exactly match up with its intended use.

How should this be tested? Do these changes have associated tests?
I'm not entirely sure how this should be tested, the easiest might be to add some basic logging into CollectionSpaceJaxRsApplication and test that you can see it, e.g.:

diff --git a/services/JaxRsServiceProvider/src/main/java/org/collectionspace/services/jaxrs/CollectionSpaceJaxRsApplication.java b/services/JaxRsServiceProvider/src/main/java/org/collectionspace/services/jaxrs/CollectionSpaceJaxRsApplication.java
index d2f4d9ca0..0eab23403 100644
--- a/services/JaxRsServiceProvider/src/main/java/org/collectionspace/services/jaxrs/CollectionSpaceJaxRsApplication.java
+++ b/services/JaxRsServiceProvider/src/main/java/org/collectionspace/services/jaxrs/CollectionSpaceJaxRsApplication.java
@@ -118,6 +118,7 @@ public class CollectionSpaceJaxRsApplication extends Application implements Reso
     private ServletContext servletContext = null;

     public CollectionSpaceJaxRsApplication() {
+        System.out.println("Initializing CollectionSpaceJaxRsApplication");
         //
         // Instantiate all our JaxRS resources
         //

Otherwise, build CollectionSpace and run the integration tests against the server.

Dependencies for merging? Releasing to production?
Testing should be done if any of the startup tasks fail to ensure the server startup does not continue.

Has the application documentation been updated for these changes?
No. I don't know if we have any technical docs on how Resteasy is configured in CollectionSpace.

Did someone actually run this code to verify it works?
@mikejritter ran the integration tests locally

Have any new security vulnerabilities been handled?
n/a

This allows us to perform the tasks done by CSpaceResteasyBoostrap
which are a mix of updating the Resteasy context and post-init tasks.
@mikejritter

Copy link
Copy Markdown
Contributor Author

Tested an exception being thrown from CSpaceRestasyBoostrap and confirmed it will cause the webapp startup to halt as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant