apache
[Proposal] Make ActiveMQ Classic more pluggable (Part 1)
Hi community. As I am diving into the plugin architecture of ActiveMQ and its plugin ecosystem, I have some ideas and would like to see what the community thinks.
What's the purpose ? Is it about ActiveMQ broker plugins and filter ? or more global ?
For the later, I started a "big change" for ActiveMQ 7 by removing Spring dep.
What is a real-world use case for the proposed methods being added at the broker level?
What about just using a destination interceptor? It may still be better to enhance the broker plugin to consolidate things but i think all the methods could be accessed today but adding a custom destination interceptor
Thanks for the feedback @jbonofre @mattrpav and @cshannon
What's the purpose ? Is it about ActiveMQ broker plugins and filter ? or more global ?
It is about ActiveMQ overall. I am brainstorming how to make ActiveMQ more plugin friendly and notice there is a potential for the BrokerFilter to intercept destination-level operation to enable a plugin to do more. However, the bigger picture is how do we make ActiveMQ more pluggable in general (some ideas include transport protocol as pluggin ... just thinking out loud) I think this can be a great first step and would like to hear what you all think.
What is a real-world use case for the proposed methods being added at the broker level?
So the idea is to make a plugin more powerful, so it is hypothetical at this point. Do you have concern over adding those to the BrokerFilter?
What about just using a destination interceptor? It may still be better to enhance the broker plugin to consolidate things but i think all the methods could be accessed today but adding a custom destination interceptor
That is a really good point. I actually thought about it while I was writing this short proposal. The issue in my opinion is if you write a Destination Interceptor (and inject that in activemq.xml) then let's say I want to write a plugin that involves those missing destination methods, I would need to write it in two parts. Given there are precedent of destination level operation exposed on BrokerFilter I think adding it to the BrokerFilter will create a better dev experience. What do you all think?
That is a really good point. I actually thought about it while I was writing this short proposal. The issue in my opinion is if you write a Destination Interceptor (and inject that in activemq.xml) then let's say I want to write a plugin that involves those missing destination methods, I would need to write it in two parts. Given there are precedent of destination level operation exposed on
BrokerFilterI think adding it to the BrokerFilter will create a better dev experience. What do you all think?
Adding more things to the BrokerFilter for a plugin is probably fine I was just curious if you had looked at the interceptor to see if it could work for your use case today. As you pointed out, the one problem is things are not consolidated and that's where a plugin helps.
I wonder if for AMQ 7.x we should re-work the plugin API a little bit and split things out. In Artemis I contributed the plugin API and separated things into different interfaces to make it a bit simpler to implement. We could do something like that too for AMQ 7 and plugin implementations could optionally implement different interfaces for what they want to do (destination plugins, etc).
I don't think we should add operations that cross domain/object boundaries. If there is a need to cross boundaries (or maintain context across boundaries) then a developer can simply implement multiple plugin interfaces as needed.
The Plugin API shared by Chris is a good example of doing that.
ActiveMQ already essentially has that, it just isn't clearly separated into a neat package/jar.
I see! Let me go back to the drawing board and give this proposal a few more thoughts. Thanks for the feedback folks!