Skip to content

[6.2.x] Send advisory messages using Broker connection context (#2071)#2075

Open
cshannon wants to merge 1 commit into
apache:activemq-6.2.xfrom
cshannon:backport-2071-6.2.x
Open

[6.2.x] Send advisory messages using Broker connection context (#2071)#2075
cshannon wants to merge 1 commit into
apache:activemq-6.2.xfrom
cshannon:backport-2071-6.2.x

Conversation

@cshannon
Copy link
Copy Markdown
Contributor

@cshannon cshannon commented Jun 4, 2026

Note: This change adds a new method to the Broker API. Most users should be ok if they use the BrokerFilter for plugins (the most common scenario) but it's possible this could be a breaking change, however the update I think is worth it. We can document the change in release notes.

This updates the AdvisoryBroker to always publish advisory messages that were generated by other events to use the Broker's own ConnectionContext. Before this change the AdvisoryBroker was using the original ConnectionContext that used used for the action that triggered the advisory. This doesn't make sense because its actually the broker itself firing the advisory message and not the original connection. It also meant requiring all users to be given access to create new advisory topics that could be created on demand.

After this update, all users no longer need permission to create advisory destinations which was required previously. Users only need read access to the temporary destination advisories for the AMQ client as the broker itself will now use its own context going forward to create all the destinations on demand and for publishing.

This update also consolidates the on consumer with no messages advisory into the Advisory broker so it is all managed in one location.

(cherry picked from commit 3598fc5)

This updates the AdvisoryBroker to always publish advisory messages
that were generated by other events to use the Broker's own
ConnectionContext. Before this change the AdvisoryBroker was
using the original ConnectionContext that used used for the action that
triggered the advisory. This doesn't make sense because its actually the
broker itself firing the advisory message and not the original
connection. It also meant requiring all users to be given access to
create new advisory topics that could be created on demand.

After this update, all users no longer need permission to create
advisory destinations which was required previously. Users only need
read access to the temporary destination advisories for the AMQ client
as the broker itself will now use its own context going forward to
create all the destinations on demand and for publishing.

This update also consolidates the on consumer with no messages advisory
into the Advisory broker so it is all managed in one location.

(cherry picked from commit 3598fc5)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

Development

Successfully merging this pull request may close these issues.

1 participant