Replace brittle Tomcat server.xml/web.xml patches with a robust mechanism

Context

The Docker image configures Tomcat by patching the base image's stock config files:

• docker/tomcat/serverxml.patch — adds the HTTPS connector, enables the thread-pool connector, comments out the plain 8080 connector.
• docker/tomcat/webxml.patch — adds a CONFIDENTIAL transport-guarantee security constraint.

These are context diffs pinned to a specific server.xml/web.xml. When the Tomcat base image changes those files, the context lines drift and the patch fails at docker build time.

This just bit us during the JDK 8 → 17 upgrade (#802 / PR #847): the Tomcat 9 base image (9.0-jre17-temurin) added maxParameterCount="1000" to its connectors, shifting context lines and causing serverxml.patch Hunk #1 to fail — breaking the Docker Compose Build CI step. Fixed in PR #847 by regenerating the patch, but the underlying fragility remains.

Problems

• Fragile across Tomcat upgrades: every base-image bump risks breaking the patch; failures only surface at image build time, not in a unit test.
• Hard to read: serverxml.patch toggles which connectors are commented out — the intent isn't obvious from the diff.
• The database.properties / mongo.properties files in the Dockerfile are generated fresh with printf (robust); only the XML config is patched (fragile).

Proposal

Replace the patch step with one of:

• Full config files — commit a complete server.xml + web.xml with the HTTPS connector and CONFIDENTIAL constraint baked in, and COPY them into the image instead of patching. No more context-drift breakage; cost is owning the full config and re-syncing on major Tomcat changes.
• Targeted in-place edits — use sed/xmlstarlet in the Dockerfile to uncomment the thread-pool connector and append the HTTPS connector. More resilient than a context diff, smaller than full files, but still some fragility if Tomcat restructures the XML.

Acceptance criteria

• docker/tomcat/*.patch removed (or the patch mechanism replaced).
• HTTPS connector (port 8443, keystore wiring via the existing TLS_KEYSTORE_FILE / TLS_KEYSTORE_PASS / ALIAS / HTTPS_PORT build args) preserved.
• CONFIDENTIAL transport-guarantee security constraint preserved.
• docker compose build succeeds; resulting container serves HTTPS and redirects HTTP → HTTPS as before.
• Approach is resilient to (or at least fails loudly/early on) Tomcat base-image config changes.

Related

• #802 — JDK 8 → 17 upgrade (introduced the Tomcat 8 → 9 bump that exposed this)
• PR #847 — regenerated the patch as a stopgap

Start by reading docker/tomcat/serverxml.patch, docker/tomcat/webxml.patch, and the Dockerfile steps that apply them, then inspect the related Tomcat configuration context. Compare the proposed full-file and targeted-edit approaches against the listed TLS and redirect requirements. Done means the patch mechanism is replaced, docker compose build succeeds, and HTTPS plus HTTP-to-HTTPS behavior are preserved.