feat(#158): DC→TP notification contract + TP-receiver stub#163
Merged
Conversation
Pin the DataCustodian→ThirdParty BatchList notification seam with a single-source-of-truth wire codec, a repo-root contract fixture, and two-sided contract tests — the DC→TP analogue of #150/#160. - BatchListXmlCodec (openespi-common): the canonical ESPI BatchList XML marshal/unmarshal codec, a stateless static utility mirroring EspiBatchUri. Both the DC sender and TP receiver route through it so neither can drift. - DC sender (NotificationServiceImpl): migrated off legacy RestTemplate to RestClient; now marshals the JAXB DTO (not the JAXB-less entity, which never serialized) and builds the resource URI via EspiBatchUri.batchSubscription. Constructor adds no new injected bean. - TP receiver (NotificationController): unmarshals via the codec to BatchListDto (fixing a latent cast to the JAXB-less entity); fetch-back stays stubbed (TP last, #146). - Removed the now-unused RestTemplate bean from DC WebConfiguration. - contracts/notification-batchlist.xml + README section document the endpoint path, application/atom+xml content type, and BatchList shape. - Tests: BatchListXmlCodecTest (round-trip + fixture, common), NotificationServiceImplWireContractTest (producer end-to-end against a JDK HttpServer TP-receiver stub — no new deps), NotificationWireContractTest (TP consumer binds to the fixture). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ired With two explicit constructors (production + test-seam) and none annotated, Spring could not select one ("No default constructor found"), failing every full-context @SpringBootTest (DataCustodianApplication{H2,Mysql,Postgres}Test). Annotate the production constructor so Spring uses it for autowiring. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This was referenced Jun 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #158.
Pins the DataCustodian→ThirdParty
BatchListnotification seam with a single-source-of-truth wire codec, a repo-root contract fixture, and two-sided contract tests — the DC→TP analogue of #150/#160. Lightweight consumer-driven contract (no Spring Cloud, no WireMock); standalone EC2 services.What changed
Shared codec —
BatchListXmlCodec(openespi-common)The canonical ESPI
BatchListXML marshal/unmarshal codec, a stateless static utility mirroringEspiBatchUri. Both the DC sender and TP receiver route through it, so the wire format cannot drift between the two services. Wire type is the JAXBBatchListDto(<BatchList xmlns="http://naesb.org/espi">), never the JPA entity — per the project's JAXB/JPA separation rule.DC sender —
NotificationServiceImpl(deliverable #3, done properly)RestTemplate→RestClient.BatchListEntity, which never serialized — so this also fixes a latent bug.EspiBatchUri.batchSubscription(Batch/Subscription/{id}?published-min=…&published-max=…).application/atom+xml. Constructor adds no new injected bean (buildsRestClientinternally; a test ctor injects one) → zero wiring blast-radius.RestTemplatebean from DCWebConfiguration.TP receiver —
NotificationControllerBatchListDto, fixing a latent cast to the JAXB-less entity.Contract fixture
contracts/notification-batchlist.xml+ README section documenting the endpoint path,application/atom+xmlcontent type, and BatchList shape.Tests
BatchListXmlCodecTest(common) — round-trip, prefix-agnostic DOM assertion of root element + namespace, and binds to the shared fixture.NotificationServiceImplWireContractTest(common) — producer end-to-end: drives the real sender against a minimal standalone TP-receiver stub (a JDKHttpServer— no WireMock, no Spring, no Docker), asserting the bytes on the wire (path, content type, parsed Batch/Subscription URI). This is the issue's "TP-receiver stub" (deliverable Bump org.postgresql:postgresql from 42.7.4 to 42.7.7 in /openespi-datacustodian/OpenESPI-GreenButton-Workspace/OpenESPI-DataCustodian-java #2).NotificationWireContractTest(thirdparty) — TP consumer binds its parsing logic to the same fixture.@DisabledNotificationControllerTests(referenced the removed marshaller; tested nothing).Verified locally: common (codec + producer stub tests pass, jar installed), thirdparty (consumer test passes), datacustodian (compiles; no test referenced the removed bean).
Out of scope (TP last — #146)
TP DB provisioning, fetch-back completion (empty access token / commented authorization lookup), re-enabling the DC sender's production callers.
🤖 Generated with Claude Code