David Martin created ARTEMIS-2633:
-------------------------------------
Summary: Enhance broker plugin framework to facilitate ActiveMQ v5
plugin migration
Key: ARTEMIS-2633
URL: https://issues.apache.org/jira/browse/ARTEMIS-2633
Project: ActiveMQ Artemis
Issue Type: Improvement
Components: Broker
Affects Versions: 2.11.0
Reporter: David Martin
Note I intend to implement this ticket myself and submit a PR but want a ticket
to track it with (and make sure there is general agreement with what I'm
proposing first).
I am trying to migrate a service from ActiveMQ v5 "classic" to ActiveMQ
Artemis - which on the whole is going to be painless with many benefits gained
like better performance, JMSv2, high availability on durable topic subs, to
name but a few.
However there is one blocker, in that the ActiveMQ v5 broker plugin framework
is a little more extensive in terms of what it enables one to do than the
Artemis equivalent.
The use case is that the ActiveMQv5 clients of this particular service
subscribe to what I call a "pseudo topic" like {{"subscription.1"}} which needs
to be mapped to a real topic string broker-side depending on the user's content
rights e.g. {{"foo.*.bar.#"}}. Also a message selector is generally added to
narrow it down further.
Also, subscribers need to be identified as having a "customer" role before
their subscriptions are manipulated in this way.
What's verified as already possible in Artemis is:
1. Override the {{Filter}} in {{beforeCreateConsumer()}}
2. Override message content & headers in {{beforeSend()}} as per existing
broker plugin example
What's *missing* in order to migrate my existing AMQv5 plugin and hence the
reason for raising this ticket is:
1. Extend {{ServerSession}} & {{ServerSessionImpl}} to expose {{public
Stream<String> getUserRoles()}} so that a plugin can track users of interest
based on their role(s), by overriding {{afterCreateSession()}}
2. Extend the plugin architecture with hooks into
{{ServerSessionImpl.createAddress()}} e.g. as {{String
ActiveMQServerPlugin.}}{{beforeCreateAddress(String name, RoutingType
routingType, boolean autoCreated)}} (with a default impl returning the same
name) to be able to override the name before creation. None of the existing
plugin methods can intercept this event as it is triggered via the transport
layer, not {{ActiveMQServerImpl}} which calls all existing plugin methods. For
completeness will also add {{void
ActiveMQServerPlugin.}}{{afterCreateAddress(AddressInfo addressInfo, boolean
autoCreated)}}.
I've proven the concept for (2) by overriding the address name in a debugger.
It succeeded without error whether the address existed already or not (after
being overridden).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
