Reaper 5.0 updates its security dependencies and Java baseline

Reaper 5.0.0, released on July 8, includes security updates for Netty and Jackson. It also moves the application to Java 17 and Dropwizard 5 with Jetty 12.1. An operator assessing this release needs to account for the runtime change as well as the dependency updates.

I consider the repair orchestrator part of the system being operated when choosing Cassandra. My enthusiasm for Cassandra comes from its ability to address active-active requirements at scale. That choice also brings management software whose dependencies and runtime need maintenance. Updating the database alone would leave that work incomplete.

The release notes identify several vulnerability fixes, but they do not establish that every Reaper installation exposes each affected code path. I would use the announcement to identify an upgrade candidate, then examine the actual artifact and configuration in use. A dependency finding and a demonstrated installation-specific exposure are related evidence with different scopes.

The released dependency graph is the useful reference

The tagged server Maven configuration identifies the versions selected by the release. It sets Netty handler and native epoll transport dependencies to 4.2.15.Final. It also manages several transitive Netty codec dependencies at that version.

That distinction matters when reviewing a security update. A direct dependency declaration does not, by itself, describe every related artifact introduced transitively. The tagged configuration explicitly addresses codec artifacts that arrive through another dependency chain. I would examine the resolved build output before claiming that a particular deployed package contains only the intended versions.

The Jackson entries also deserve individual reading. The release declares jackson-databind and jackson-core at 2.21.4, while jackson-annotations uses 2.21. Those declarations should not be normalized into a single invented patch version in an inventory. Annotations has a different version string in the actual release configuration.

I would record the deployed artifact's identity alongside any dependency assessment. A source tag describes the project inputs. A running container or locally rebuilt package still needs to be associated with those inputs. Otherwise an upgrade ticket could be closed against the right release notes while the deployment continues using an older image.

The Java baseline changes the deployment requirement

The server build sets compiler source, target and release to 17. The tagged main Dockerfile starts from an Amazon Corretto 17 Alpine image. These are concrete runtime and build changes that belong in the upgrade assessment.

For an installation that supplies its own JVM, I would identify the executable used by the service launcher. An interactive shell's Java version would not establish which runtime a service manager selects. A custom image would need the same scrutiny because it may replace the project's base image while retaining its application package.

The Java and Dropwizard migration patch also updates the coverage tooling. Its description explains that an older JaCoCo agent could not instrument Java 17 bytecode, producing misleading test symptoms. That is useful context for anyone building the release locally.

I would not generalize the patch author's test results into a claim about an independently built package. The useful lesson for a local build is to preserve the release's toolchain assumptions and inspect failures at the level where they occur. A test infrastructure failure is different from a failed repair-workflow assertion, and both need an explanation before accepting the build.

The web framework migration reaches application integration

The tagged build selects Dropwizard 5.0.2 and Jetty 12.1.10. The initial migration patch used an earlier Jetty patch version, so the final tag is the better source for the released number. This is why I prefer to check dependency declarations after reading the change proposal.

The tagged application initialization code imports the session handler and cross-origin filter from Jetty's EE10 packages. It also changes how it traverses server handlers. These are application integration changes accompanying the dependency migration.

For deployment acceptance, I would exercise the access path users and automation actually use. An application that starts successfully still needs to serve the intended authenticated requests. If an installation enables cross-origin access, I would include the configured browser workflow in that check. These are proposed checks based on the integration points visible in the code, not reports of a known regression.

The same reasoning applies to monitoring. I would verify that the upgraded process produces the observations the installation relies on. A clean dependency inventory would not show whether an operator can still identify a stalled repair or inspect a schedule through the deployed configuration.

Container maintenance is part of the package

The release notes also include a change described as fixing image vulnerabilities. The Dockerfile explicitly upgrades OpenSSL while installing its operating-system packages. That places some security maintenance below the Java dependency graph.

I would therefore retain both application and image information in the deployment record. Updating a JAR in an old custom image would produce a different artifact from adopting the project's new container. A finding against the image's packages needs to be checked against the image actually deployed.

The tagged Dockerfile runs as a dedicated Reaper user and defines a persistent storage directory. I would verify that a replacement image can still access the intended mounted data with the installation's permissions. A runtime update should be accepted with evidence that the process has opened the expected state, rather than merely created an empty replacement directory.

For a rehearsal, I would use a copy of the existing application state and a bounded repair workflow. The acceptance result should establish that the intended artifact starts on the selected JVM and uses the expected storage. It should also show a scheduled run progressing through the relevant workflow. The final deployment record can then connect the dependency fixes with a verified operating configuration.