From 8f5184e4db8b3eac3b1618fc271b240028f09e8a Mon Sep 17 00:00:00 2001 From: Ken Liao Date: Wed, 12 Mar 2025 23:09:01 -0700 Subject: [PATCH 1/2] add design doc --- .../broker_filter_change.md | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 docs/proposal/more_pluggable_activemq/broker_filter_change.md diff --git a/docs/proposal/more_pluggable_activemq/broker_filter_change.md b/docs/proposal/more_pluggable_activemq/broker_filter_change.md new file mode 100644 index 00000000000..a2a71cbe38c --- /dev/null +++ b/docs/proposal/more_pluggable_activemq/broker_filter_change.md @@ -0,0 +1,34 @@ +## More pluggable ActiveMQ Part I : add more destination control on ActiveMQ Classic `BrokerFilter` + +### Problem statement + +ActiveMQ Classic natively supports plugin architecture through `BrokerFilter` and dependency injection at runtime defined in `activemq.xml`. There are already a few plugins shipped with ActiveMQ Classic main branch (such as `SimpleAuthenticationPlugin`) that users can configure on `activemq.xml` out of the box. Furthermore, it can support external plugins hosted outside of its main branch (see this [blog post](https://medium.com/p/9cafcb39fbe4) and the [public doc](https://activemq.apache.org/components/classic/documentation/developing-plugins) for more details). That said, there are ways to make the broker engine more pluggable. This design doc is the first part of a bigger discussion, to make ActiveMQ Classic more pluggable and grow its plugin ecosystem. This design doc proposes that the `BrokerFilter` should expose more destination level operations to be intercepted. Note, there are many other avenues to explore, like making transport protocol more pluggable … etc. + +### Rationale + +By exposing more destination-level events on `BrokerFilter`,a plugin will have more control and allows a plugin to support more features related to destination operations. + +### Proposal + +In the current state, here are the methods exposed in the `BrokerFilter` that intercept destination-level operations: + +1\. `addDestinationInfo` +2\. `removeDestinationInfo` +3\. `getDestinations` +4\. `getDestinationMap` +5\. `getDurableDestinations` +6\. `addDestination` +7\. `removeDestination` +8\. `virtualDestinationAdded` +9\. `virtualDestinationRemoved` + +We will add the following method to the `BrokerFilter`: + +1\. `purgeDestination` method + +- This method is triggered when a destination is about to be purged. + +2\. `markDestinationForGC` method + +- This method is triggered when a destination is about to be marked for GC + From f30d1f983e79af22389711628173749e28e911f7 Mon Sep 17 00:00:00 2001 From: Ken Liao Date: Fri, 21 Mar 2025 12:27:56 -0700 Subject: [PATCH 2/2] Update broker_filter_change.md --- .../broker_filter_change.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/docs/proposal/more_pluggable_activemq/broker_filter_change.md b/docs/proposal/more_pluggable_activemq/broker_filter_change.md index a2a71cbe38c..7fb4555d412 100644 --- a/docs/proposal/more_pluggable_activemq/broker_filter_change.md +++ b/docs/proposal/more_pluggable_activemq/broker_filter_change.md @@ -2,8 +2,7 @@ ### Problem statement -ActiveMQ Classic natively supports plugin architecture through `BrokerFilter` and dependency injection at runtime defined in `activemq.xml`. There are already a few plugins shipped with ActiveMQ Classic main branch (such as `SimpleAuthenticationPlugin`) that users can configure on `activemq.xml` out of the box. Furthermore, it can support external plugins hosted outside of its main branch (see this [blog post](https://medium.com/p/9cafcb39fbe4) and the [public doc](https://activemq.apache.org/components/classic/documentation/developing-plugins) for more details). That said, there are ways to make the broker engine more pluggable. This design doc is the first part of a bigger discussion, to make ActiveMQ Classic more pluggable and grow its plugin ecosystem. This design doc proposes that the `BrokerFilter` should expose more destination level operations to be intercepted. Note, there are many other avenues to explore, like making transport protocol more pluggable … etc. - +ActiveMQ Classic natively supports plugin architecture through `BrokerFilter` and dependency injection at runtime defined in `activemq.xml`. There are already a few plugins shipped with ActiveMQ Classic main branch (such as `SimpleAuthenticationPlugin`) that users can configure on `activemq.xml` out of the box. Furthermore, it can support external plugins hosted outside of its main branch (see this [blog post](https://medium.com/p/9cafcb39fbe4) and the [public doc](https://activemq.apache.org/components/classic/documentation/developing-plugins) for more details). That said, there are ways to make the broker engine more pluggable. This design doc is the first part of a bigger discussion, to make ActiveMQ Classic more pluggable and grow its plugin ecosystem. This design doc proposes that the `BrokerFilter` should expose more destination level operations to be intercepted. ### Rationale By exposing more destination-level events on `BrokerFilter`,a plugin will have more control and allows a plugin to support more features related to destination operations. @@ -22,13 +21,17 @@ In the current state, here are the methods exposed in the `BrokerFilter` that in 8\. `virtualDestinationAdded` 9\. `virtualDestinationRemoved` -We will add the following method to the `BrokerFilter`: +We propose to add the following method to the `BrokerFilter`: -1\. `purgeDestination` method +1\. `purgeDestination()` method - This method is triggered when a destination is about to be purged. -2\. `markDestinationForGC` method +2\. `markDestinationForGC(long timeStamp)` method + +- This method is triggered when a destination is marked for GC + +3\. `browseDestination()` method -- This method is triggered when a destination is about to be marked for GC +- This method is triggered when a destination is browsed