feat(messaging): connect to an external ActiveMQ broker - #6870
Merged
Conversation
Adds DIRIGIBLE_MESSAGING_BROKER_URL/_USERNAME/_PASSWORD so a deployment can point its messaging at an external broker instead of the embedded one, and adopts DIRIGIBLE_MESSAGING_USE_DEFAULT_DATABASE into the enum so its key has a single owner (it was a bare string literal read in MessagingConfig plus a staticParams entry; getConfigParams unions the enum keys, so it stays exposed). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The messaging beans were one configuration that always started an in-process broker and attached to it over vm://localhost. It is now split in two, selected by whether a broker URL is configured: the embedded half is the previous configuration unchanged, the external half builds the connection factory from the configured URL and credentials and defines no BrokerService at all. Everything downstream is untouched: both halves keep the ActiveMQConnection and ActiveMQSession bean names, and every consumer - the .listener artifacts, the client-Java listeners, the messaging facade - reaches the broker through ActiveMQConnectionArtifactsFactory, which resolves the connection factory by type. The conditions read Dirigible's own configuration rather than the Spring Environment, because a value set programmatically (how the integration tests select the mode) never reaches the Environment. Shutdown no longer requires a broker to exist: with an external broker there is none to stop, and the connection and session are still closed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ed broker Both the service and its endpoint read state out of the in-process BrokerService object, which does not exist when the messaging is pointed at an external broker - as written, the context would fail to start there. They are now conditional on the embedded mode, so an external-broker deployment simply has no monitoring endpoints and the perspective's calls answer 404; that broker is administered from its own console. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Starts a real ActiveMQ on a TCP port from the test, points the platform at it before the Spring context exists, and asserts what external mode has to hold: a .listener handler consumes a published message, no BrokerService bean was created, the connection factory carries the configured URL, the connection and session beans the engine consumes are still there, and the monitoring beans - which read the in-process broker - are absent instead of failing the startup. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| String username = DirigibleConfig.MESSAGING_BROKER_USERNAME.getStringValue(); | ||
|
|
||
| warnIfEmbeddedOnlyConfigIsSet(); | ||
| LOGGER.info("Messaging will use the external ActiveMQ broker at [{}] with user [{}]", brokerUrl, username); |
| String username = DirigibleConfig.MESSAGING_BROKER_USERNAME.getStringValue(); | ||
|
|
||
| warnIfEmbeddedOnlyConfigIsSet(); | ||
| LOGGER.info("Messaging will use the external ActiveMQ broker at [{}] with user [{}]", brokerUrl, username); |
iliyan-velichkov
added a commit
to dirigible-io/dirigible-io.github.io
that referenced
this pull request
Aug 20, 2026
…209) Documents DIRIGIBLE_MESSAGING_BROKER_URL and its credentials (eclipse-dirigible/dirigible#6870): a Messaging section on both env-var pages, a "Broker - embedded or external" section on the message-listeners page, and an "Embedded broker only" note on the messaging perspective, whose endpoints answer 404 against an external broker. Also corrects the pages that asserted an embedded-only broker - the producer SDK page promised "no broker URL, no client configuration".
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
2 participants
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.
What
Messaging can now be pointed at an external ActiveMQ broker instead of the embedded one:
Unset (or blank) — which is every existing deployment — keeps today's behaviour exactly: an
in-process
BrokerServicereached overvm://localhost.Why
Several deployments sharing one broker is what makes cross-deployment queues usable (the
global:destinations shipped in v14.29.0 assume it), and a managed broker such as Amazon MQ is what a
multi-node or containerised deployment wants rather than a broker embedded in each node.
How
MessagingConfigbecomes two configurations selected by whether a broker URL is configured:EmbeddedBrokerMessagingConfigExternalBrokerMessagingConfigEmbeddedMessagingBrokerConditionExternalMessagingBrokerConditionvm://localhost?create=falseActiveMQBrokerbeanActiveMQConnection/ActiveMQSessionThe conditions are the exact negation of one another, so exactly one always applies.
Nothing downstream changes: every consumer — the
.listenerartifacts, the client-Java listeners inengine-java,MessagingFacade— reaches the broker throughActiveMQConnectionArtifactsFactory,which resolves the
ActiveMQConnectionFactoryby type. Swapping that one bean is the wholechange.
Two consumers of the now-optional broker bean were adjusted:
CloseActiveMQResourcesApplicationListenertakes anObjectProvider<BrokerService>and stillcloses the listeners, session and connection in both modes.
MessagingMonitoringServiceandMessagingMonitoringEndpointread broker state out of thein-process object, so they are conditional on the embedded mode. With an external broker they are
not registered and the messaging perspective's calls answer 404 — such a broker is administered
from its own console. This is the one user-visible behaviour change, and only in the new mode.
Notes for reviewers
DirigibleConfig, not the SpringEnvironment— this is the firsthand-written
Conditionin the repo. Dirigible resolves a key across its own layers and a valueplaced there programmatically (
Configuration.set, which is how the IT selects the mode) neverreaches the
Environment, so@ConditionalOnPropertycannot see it.DIRIGIBLE_MESSAGING_USE_DEFAULT_DATABASEmoved into theDirigibleConfigenum (its key had beena bare string literal plus a
staticParamsentry;getConfigParams()unions the enum keys, so itstays exposed). It configures the embedded broker's persistence only and is logged as ignored in
external mode.
IllegalStateException.build/helm-charts/dirigible/templates/dirigible.yamlwas not extended with the new keys; saythe word if the chart should carry them.
Testing
mvn -pl components/engine/engine-listeners -am clean install -P unit-tests— 64 tests pass.New:
MessagingBrokerConditionsTest(mode selection, blank handling, mutual exclusivity),MessagingConfigSelectionTest(pins the bean-graph shape of both modes),ExternalBrokerMessagingConfigTest(URL/credentials, anonymous connection, the ignored-config log,and that the password never reaches the log). Updated:
CloseActiveMQResourcesApplicationListenerTest.ExternalMessagingBrokerITstarts a real ActiveMQ on a random TCP port, points the platform atit before the context exists, and asserts a
.listenerhandler consumes a published message, thatno
BrokerServicebean exists, that the connection factory carries the configured URL, and thatthe monitoring beans are absent.
MessagingFacadeIT,GlobalDestinationITandJavaListenerTenantITpass unchanged.
mvn -T 1C formatter:validateclean.🤖 Generated with Claude Code