Full Changelog 7.1.2

Replace the local config_custom_data.xml file and ACS-owned tables with a read-only consumer of the config-custom-data Hazelcast snapshot published by ft-configs-service. The device-session hot path reads an in-memory near-cache indexed by manufacturer/model (plus a global bucket); on snapshot change every node rebuilds the near-cache and a single node reconciles device subscriptions (notification off for removed mappings) via a Hazelcast lock against a cluster-authoritative baseline. Graceful degradation on a missing/empty snapshot keeps the last-known mappings without blocking readiness.

Remove the legacy write path (file watcher, JAXB types, syncConfigCustomData topic) and the dead configureAccountInfoMapping/getAccountInfoMapping SOAP methods. Deprecate the config_custom_data / config_custom_param DAOs and entities (physical table drop deferred). Update the Custom Data Mapping documentation.

The runtime read version.xml from the config directory, which QA and customer deploys bind-mount from the host, so a stale host file shadowed the copy baked into the image. The entrypoint compensated by overwriting conf/version.xml on every start, i.e. the container wrote into the operator’s host directory. A second, independent defect made the same symptom worse: DMConfigurationInitializer strips five characters from spring.config.additional-location expecting a "file:" prefix, but both start.sh and the compose entrypoint pass a bare path, leaving a relative garbage HOME_DIR that never resolves.

Follow northbound-api instead: the build copies the root version.xml into the distribution, so it ships next to the application at ${APP_HOME}, and the runtime reads it relative to the process working directory. Unlike northbound-api there is deliberately no classpath fallback, because start.sh puts patches/, ext/ and conf/ ahead of app/ on the classpath - a fallback would silently resolve the very bind-mount this change removes.

Missing or unparsable input now degrades to "unknown" instead of null and logs a warning naming the exception class, so the banner and acs_info.acs_version can no longer read "V null Build null(null)". The XML parser is hardened against XXE.

The Dockerfile keeps one explicit copy of the single file so that a stale target/dist fails the image build loudly instead of shipping a version-less image.

Tests do not run in CI (build-skip-tests is active by default); see docs/decisions/LOG.md.

ReasonPhraseHttp11Processor.isSupported() reflected only the lookup of Http11Processor.outputBuffer. Had a JDK refused the final-field write, every new processor would have allocated a buffer, copied the filters, caught the exception and kept the stock buffer, while TomcatMultiPortConfig never logged its WARN and left the connectors on the custom protocol - contrary to what findings.md section 6.2 claimed.

The swap is now performed for real on a throwaway processor when the class is initialised (probeSwap); isSupported() returns that outcome and processors skip the attempt entirely when it failed. The probe protocol supplies an HttpParser so an unstarted Http11NioProtocol does not make Tomcat log about a missing one at ACS startup.

ReasonPhraseHttp11ProcessorTest pins it: the probe succeeds on the real field, fails on a field of another type and on null, and a processor from createProcessor() carries a ReasonPhraseOutputBuffer. 15/15 green with JDK 25 and tomcat-embed-core 11.0.22 (javac -proc:full so Lombok runs on JDK 23+).

Docs aligned with the code: findings.md 5.4/6.1/6.2/6.3 (6.2 also states that the tests are not run by the default build-skip-tests profile), README_probe.md no longer suggests a proxy or a container swap, and the CpeAuthChallenge javadoc points at ReasonPhraseOutputBuffer instead of saying the phrase cannot be restored.

A fourth review round rated one gap MEDIUM: an Error from the probe - realistically only a LinkageError when the Tomcat jar on the classpath is not the one the ACS was compiled against - escaped <clinit>, poisoned the class and would have failed the startup through connectorProtocol(), contrary to the documented fail-safe. probeSwap and swapOutputBuffer now catch LinkageError as well, and TomcatMultiPortConfig.reasonPhraseSupported() catches one thrown by the class initialisation itself, logs an ERROR and falls back to the stock protocol. 15/15 green after the change; findings.md 6.2/6.3 updated.

Uncommitted AsciiDoc edits were wiped by a git reset --hard on master; reconstructed from the last known-good rendered HTML preview (ft-acs/6.5.3/installation.html, configuration.html).

Re-applies mechanical Asciidoctor-cleanliness fixes lost when master was literal {name} attribute references in prose/inline-code across ACS design pages, restart manually-numbered lists in changelog.adoc with where prose/listings broke the outline, drop the dead media/image3.emf workflow image in prov-separation.adoc, and remove the unsupported :page-layout: release-notes attribute from the 2025 ACS release-notes pages.

Matches the UI Backend guide: peers running on the same host but outside Docker are unreachable as localhost from inside the container.

The guide told operators to mount ftacs/config read-only, and at least one environment followed it. That mount silently breaks the QoE syncs: the ACS writes mac_path.csv and gpv_models.csv into the same directory at runtime, and both writers only log the IOException instead of failing, so the files just go stale with nothing obviously wrong. On older images the entrypoint also failed there with "Read-only file system" while copying version.xml.

Drop :ro from the three config-mount examples, correct the four places that described the mount as read-only, and add a troubleshooting entry naming the symptom so support can recognise it instead of guessing.

The single-file sensitive_params.xml mount stays read-only - it is a different mount and correctly immutable. The startup version banner is

The design rationale they carried lives in docs/src/modules/ROOT/pages/config-custom-data.adoc, which ships in this PR. docs/decisions/LOG.md is untouched: it predates this branch and other pages link to it.

QA has no real devices and tests against the emulator, which cannot reproduce this defect: ReactiveEmulatorClient.sendWithAuthentication branches on resp.status().code() and reads the body as bodyMono.asString().defaultIfEmpty(""), and the legacy Apache HttpClient path uses BasicCredentialsProvider/AuthScope. Neither looks at the reason phrase, both tolerate an empty body, so the emulator onboards on the broken build too and a green run proves nothing.

The check that does carry value needs no device, because the challenge is produced by the ACS regardless of who sent the Inform: capture the 401 from 6.4.14 and from 7.1.1 and diff them. That tests the acceptance criterion from the ticket directly - the response must be as it was in 6.4.x - and the expected remainder is now written down, so an unexpected difference is visible instead of being argued about.

The install and configuration guides told the story of how the password used to bind to the misspelled CLICKHOUSE_PASWORD and what that broke. Now that CLICKHOUSE_PASSWORD is the supported name, that history helps nobody setting up or upgrading a server, so both WARNING blocks lose it.

The old spelling stays where it is still operationally true: the variables tables in both guides describe it as a deprecated fallback, and the upgrade checklist still says to rename it. FTACS keeps reading it and keeps logging its name in a deprecation warning, so an operator who meets that name in a log or in their own .env has to find it documented somewhere. The installation table row absorbs the rename instruction that the deleted WARNING paragraph carried, so nothing actionable was lost with it.

Deployment Manager reads this file from the tip of this branch to know the service’s image, ports, volumes, clustering pattern and the variables an operator must fill in. It was previously vendored in ft-internal-tools (deployment-manager/catalogue/contracts/ftacs.yaml); this repository now owns it.

These are the application config files a generated Compose bundle mounts into this service’s container. They were vendored in ft-internal-tools (deployment-manager/catalogue/services/); this repository now owns them, and Deployment Manager reads them from the tip of this branch.

Private key material is deliberately NOT here: keys and keystores stay in the one place they already live and are laid over this tree at generation time, so the same private key does not gain a copy per repository.

Completes the deployment/ tree: the keystores and TLS private key a generated Compose bundle mounts into this container, which were held back from the previous commit while their placement was decided.

They are tracked here rather than in ft-internal-tools so a service’s install payload is one thing in one place. Rotating a key is now a commit in this repository — the same file was previously copied across two repositories, and a rotation had to find both.

Master replaced the raw "custom_config" literal with the shared constant in ConfigCustomDataProcessor; align the new reconciler with it. Same value, no behavior change.