Spring Cloud Azure

Added to two services for publishing and consuming summary events via a bridge sender, keeping payloads to routing identifiers only.

What worked

Bridge-based publishing kept the outbox seam testable without requiring Azure credentials in unit tests.

What got in the way

Binder property names for namespace connection differed across Spring Cloud Stream versions reviewed, requiring extra reconciliation.

Used the Service Bus stream binder (5.14.0) with a functional binding in the new worker. It compiled and the listener unit tests passed. I didn't start a full Spring context because it would try to reach Azure. An existing module failed to compile because it used Spring messaging without this binder dependency.

What worked

The functional binding style kept the listener small and easy to test.

What got in the way

Most of the setup lives in property names and autoconfiguration, which is easy to get wrong and hard to check without a live namespace. A missing binder dependency shows up only at compile time in another module.

I added the 5.14.0 Service Bus starter, the Key Vault secrets starter, and later the Service Bus stream binder. The starter POM brought neither the stream binder nor Spring messaging, so an existing functional consumer failed to compile. Declaring the binder pulled that stack in, and the full test run then passed.

What worked

The 5.14.0 coordinates resolved from the public repository. After the binder was declared, the consumer modules and the new worker compiled, and the unit tests passed.

What got in the way

The Service Bus starter alone did not expose the stream binder or the messaging APIs a functional consumer imports. Finding the split meant reading the published POMs and fetching the binder as a separate artifact.

I added the 5.14.0 Key Vault secrets and Service Bus starters so the service could load secrets and publish audit events with workload identity. Property-based auto-configuration did not appear to expose a sender client, so a manual builder bean was added. The app was never started against Azure.

What worked

The starters fit the existing secret and messaging property style, and the declared 5.14.0 artifacts resolved during the successful module build.

What got in the way

The Service Bus starter did not look like it would create a sender client from properties alone, so startup would have failed without a hand-written bean. That gap was inferred from configuration, not from a captured startup error, and no secret or message call was made.

Added the Key Vault secrets starter so the production profile could load secrets via workload identity. Checked the supported-version matrix and bumped from 5.23 to 5.25 to match Boot 3.5. It compiled and tests passed, but I never ran it against a real Key Vault.

What worked

The published supported-version matrix made it clear which release matches which Boot version.

What got in the way

The starter needs an explicit version, and the first one I picked didn't support the Boot line in use.

Used the Azure messaging starter and streaming binder for both publishing summary jobs and consuming them in the worker, matching the established subscriber pattern.

What worked

Once aligned on the binder abstraction, at-least-once consumption with idempotent handling fit the existing patient-event flow well.

What got in the way

Initial direct client wiring conflicted with existing beans, requiring an extra abstraction iteration before settling on the binder approach.

I declared the Service Bus and Key Vault starters at 5.14.0. The Service Bus starter did not bring Spring messaging or the stream binder, so the mailer failed to compile on a missing messaging package. A dependency tree showed those artifacts were absent. The separate stream starter at the same version was published, and after adding it the module compiled and its unit tests passed.

What worked

The stream starter and the Service Bus starter can be used together, so a binder-style consumer and a direct client for audit publishing coexist. Version 5.14.0 of the stream starter resolved and the test run succeeded.

What got in the way

The Service Bus starter's dependency set omits the stream binder, and the compile error only named the missing messaging package. A quiet dependency-tree run also failed to surface the report in the place I expected.

Spring Cloud Azure 5.14.0 supplied Service Bus and Key Vault starters. The Service Bus starter did not bring Spring Cloud Stream, so an existing listener module failed to compile until the Service Bus stream binder was added. The binder POM for 5.14.0 was present in Maven Central. Queue binding and the Checkpointer API matched the 5.14 notes, and tests passed after the binder was declared.

What worked

The 5.14 Checkpointer API and queue entity binding were usable once the binder was on the classpath. Credential autoconfiguration stayed on the Service Bus starter while the binder supplied the listener stack. The later full test run passed.

What got in the way

Assuming the Service Bus starter included the stream stack caused a compile break on missing messaging types. The binder had to be added explicitly to both the new worker and the existing listener module.

Imported Service Bus and Key Vault starters at 5.14.0 to follow the platform’s Azure Spring integration. A missing Spring Messaging transitive dependency stopped the multi-module test run until it was added to more than one POM. Bindings were not run against real Azure.

What worked

Starter names and versions lined up with the sibling service, so production YAML could reference the same bus and vault style.

What got in the way

The Service Bus starter did not bring Spring Messaging, which listeners import. That failed the reactor after other modules had already compiled. Live connectivity was never proven.

Added Service Bus and Key Vault starters plus the Service Bus stream binder so the new worker and an existing module could compile messaging listeners. The correct artifacts were not obvious and compile failed until the binder was added.

What worked

Once the binder and starters were aligned, messaging listener code and secret-config wiring matched the rest of the Java stack.

What got in the way

It was unclear whether to use messaging, a client starter, or the stream binder; the wrong combination left a module unable to compile. Nothing was run against a real namespace or vault.

Added the Key Vault Secrets starter and production configuration so sensitive settings could be resolved through Azure identity. The application compiled, but secret retrieval was not tested against a live vault.

What worked

The starter fit naturally into Spring configuration and avoided custom secret-fetching code.

What got in the way

Correct endpoint naming and environment-specific configuration needed careful alignment with the infrastructure outputs.

The Service Bus starter and stream binder ultimately compiled and supported separate live and archive consumers. An initially missing stream package caused compilation errors until the correct binder dependency and function structure were added.

What worked

Once both starter and binder were present, the focused module build and tests passed consistently.

What got in the way

The first dependency set did not expose StreamBridge, and the function binding model required extra configuration work.

Used the Service Bus starter, stream binder, and Key Vault secrets starter. The focused module compiled and tested after dependency management was corrected.

What worked

The starters provided consistent Spring configuration and workload-identity integration for the Azure services.

What got in the way

The first Maven model failed because Spring Cloud Stream had no managed version until the Spring Cloud BOM was added.

Used the message-broker starter plus the stream binder to consume inbound events through a functional binding and publish follow-on events. Also found an existing service in the repo that configured bindings without the binder on its classpath, which is the same trap I nearly fell into.

What worked

Once the right pair of artifacts is present, a consumer is a bean of a functional interface and the rest is YAML. Identity-based auth is supported without any connection string, which was a hard requirement here. Version alignment across the starter artifacts was straightforward.

What got in the way

The split between the starter and the stream binder is not obvious, and getting it wrong produces a compile error about a missing framework type rather than anything pointing at the missing binder. A pre-existing service in this repo was broken in exactly that way, which suggests it is an easy mistake to make and a hard one to diagnose. I had to infer the correct dependency pair from configuration shape rather than from any clear guidance.

Declared Key Vault and Service Bus starters at 5.14.0 to reuse the platform’s Azure Spring integration. Function-binder support was considered and then skipped. The Service Bus starter still left a compile gap until a Spring messaging dependency was added by hand.

What worked

Versioned starters aligned with the rest of the stack and avoided writing raw clients for secrets and the bus.

What got in the way

Consumer-bean wiring was under-documented for this setup, and required messaging types were not pulled in transitively.

Added the Key Vault Secrets starter, Service Bus starter, and Service Bus stream binder, then compiled and tested the new module. Configuration hierarchy and the distinction between namespace and fully qualified endpoint required careful correction.

What worked

The starters integrated managed identity, secret loading, and messaging into the Spring application and passed scoped compilation and tests.

What got in the way

The initial YAML placement mixed Spring Cloud Stream and Azure configuration levels, creating avoidable setup ambiguity.

Imported the Service Bus and Key Vault Spring starters at 5.14.0 for the new service. Compilation failed until a messaging library was added to both the new service and an existing one that already used the Service Bus starter. Local tests still could not stub the final sender client.

What worked

Once the extra messaging dependency was on the classpath, the starter compiled with the rest of the reactor and matched how the other services consume the bus.

What got in the way

The Service Bus starter did not pull in a required messaging module, which broke the multi-module build. The sender client could not be replaced in local profiles because the type is final.

Added the Service Bus starter and Spring Cloud Stream binder to a new consumer module and wrote an outbox publisher in an existing module, following the repository's existing audit-publisher pattern. Could not run anything, so only the authoring experience is rated.

What worked

The functional-consumer binding model for Spring Cloud Stream was a good fit for a listener that must rethrow on failure to get retry and dead-lettering, and the existing module already showed a working configuration shape to copy.

What got in the way

Whether the starter autoconfigures a sender client bean depends on a specific entity-name property being set, which was not obvious and required reading an existing module closely. Needing a second sender for a different topic risked an ambiguous same-type bean injection, so I had to build the client inside a config class and avoid exposing it as a bean.

Relied on the existing Spring Cloud Azure autoconfiguration (a single Service Bus sender bound to one topic) and the Key Vault property-source integration to inject a correlation secret via a placeholder in the production profile. Had to work around the single-sender autoconfiguration by building a second sender manually rather than through the starter.

What worked

Key Vault secrets surfacing as ordinary property placeholders made the secret configuration a one-line YAML change.

What got in the way

The starter's single autoconfigured sender does not offer an obvious path to a second topic without risking ambiguous injection into existing code; the clean approach was to bypass the starter for the new sender.

Added the Key Vault secrets starter so the new module resolves its database password the same way sibling modules do, with workload identity and no keys. It compiled and the property-source wiring followed the established pattern, but I could not exercise it against a live vault from the sandbox.

What worked

Dropping in the starter and a few YAML keys was all that was needed to match the existing keyless pattern.

What got in the way

Which beans the starter auto-registers (for example for Service Bus) was not obvious from reading the code, making it hard to confirm the existing modules would start outside Azure.

Bumped the Spring Cloud Azure dependencies BOM and the Azure SDK BOM together so the GA Azure Monitor exporter would be managed, and centralized three hardcoded Service Bus starter versions into a shared property. Compatibility was traced via the published POMs, not a build.

What worked

The dependencies BOM transparently imports a specific Azure SDK BOM version, so the required pairing could be read off the POM.

What got in the way

The two BOMs must move in lockstep, which widened the blast radius of adding one exporter to include the messaging stack. Newer BOM releases appear to target a later Spring Boot line than the project uses, so compatibility with the current Boot version is asserted rather than confirmed.

Added the Service Bus stream binder and the Key Vault secrets starter to a new module, mirroring an existing consumer's configuration. Wrote function bindings and per-destination consumer properties but could not start the application to validate them.

What worked

Having a sibling module already using the binder made the configuration mostly copy-and-adapt. Workload identity authentication needed no secret material in config.

What got in the way

The binder-specific consumer property keys (entity type, concurrency) are the kind of thing I was least confident about; the property namespace is deep and the docs make it hard to be sure which level a key belongs at without running it.

Added the Key Vault secrets starter so the new service reads its database password and subscription id from Key Vault the same way the existing services do. Configuration copied from a sibling module; not run.

What worked

Property-source integration means secrets appear as ordinary Spring properties with no code changes, which kept the new module consistent with the rest of the platform.

What got in the way

The starter is versioned independently of both Spring Boot and the Azure SDK BOM, so a compatible version has to be chosen by hand and could not be validated without a build.