[
https://issues.apache.org/jira/browse/ARTEMIS-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Martin updated ARTEMIS-2633:
----------------------------------
Description:
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).
was:
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).
> 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
> Priority: Major
>
> 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)
