Artemis already has the notification listener in place:
These are the notification currently supported: https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/CoreNotificationType.java There are a few more that still didn't merge the core model yet: https://github.com/apache/activemq-artemis/blob/master/artemis-jms-server/src/main/java/org/apache/activemq/artemis/jms/server/management/JMSNotificationType.java On Tue, Dec 20, 2016 at 2:43 PM, Christopher Shannon <[email protected]> wrote: > A plugin API is actually one of the big things on my list as well. In > 5.x it is very easy to add extra functionality at certain points in > the chain (on a new connection, new consumer, etc) and I think having > some mechanism to do that in Artemis will be useful as well. I use a > combination of plugins that come out of the box with 5.x as well as > custom ones that are specific to my use case. > > I opened up https://issues.apache.org/jira/browse/ARTEMIS-796 for > Advisory support and it might be a good candidate as a plugin as Matt > pointed out. > > On Tue, Dec 20, 2016 at 11:54 AM, Clebert Suconic > <[email protected]> wrote: >> The inbound would transform the message before it enters the broker. >> >> >> Outbound would only apply to the current delivery. >> >> >> It would be a nice feature. >> On Tue, Dec 20, 2016 at 11:44 AM Matt Pavlovich <[email protected]> wrote: >> >>> Clebert- >>> >>> >>> >>> I think outbound/inbound separation would be really handy for plugin >>> >>> writers. Are these statements correct based on what you are thinking w/ >>> >>> inbound and outbound? >>> >>> >>> >>> 1. The outboundTransformer() would transform messages for one or more >>> >>> client consumer(s) and across protocols. ie.. one JMS consumer, one >>> >>> STOMP consumer on the same address would receive the transformed copy of >>> >>> the message. >>> >>> >>> >>> 2. The outboundTransformer would _not_ transformation messages being >>> >>> sent to other brokers (replication and/or pub+sub to brokers in a cluster) >>> >>> >>> >>> 3. For the inboundTransformer.. the message would be transformed for all >>> >>> delivery into the broker for all consumers, brokers and diverts. >>> >>> >>> >>> Thanks, >>> >>> Matt >>> >>> >>> >>> On 12/20/16 10:33 AM, Clebert Suconic wrote: >>> >>> > I think we should include two options on AddressSettings: >>> >>> > >>> >>> > i - inboundTransformer >>> >>> > ii - maybe an outboundTransformer >>> >>> > >>> >>> > inboundTransformer (String address, ServerSession session, >>> >>> > ServerMessage message); >>> >>> > outboundTransformer(String address, ServerSession session, >>> >>> > ServerMessage message); >>> >>> > >>> >>> > >>> >>> > The trick part here is that outboundTransformer would need to work on >>> >>> > a copy of the message. so, the API needs to return a copy of the >>> >>> > message. >>> >>> > >>> >>> > >>> >>> > >>> >>> > I am working now on refactoring encoding and transformer between >>> >>> > protocols that would make this a bit easier. I'm at the design phase >>> >>> > and I will post a DISCUSS thread about that when I have something more >>> >>> > concrete to talk about it. >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > On Tue, Dec 20, 2016 at 11:22 AM, Matt Pavlovich <[email protected]> >>> wrote: >>> >>> >> I was taking a first step in implementing an existing ActiveMQ 5.x >>> plugin in >>> >>> >> the Artemis source and noticed that there is a gap in the availability >>> of >>> >>> >> extension points in Artemis (or plugins). >>> >>> >> >>> >>> >> I opened ARTEMIS-898 for tracking, and thought it deserved a discussion. >>> >>> >> This feels like a good target as a 2.x feature, since it would most >>> likely >>> >>> >> be API changing. It stands to reason the extension points in Artemis >>> would >>> >>> >> be very different than ActiveMQ 5.x, so I've laid it out in terms of >>> >>> >> features and capabilities. >>> >>> >> >>> >>> >> The big three: >>> >>> >> >>> >>> >> 1. Message header / property manipulation. Allows admins to set message >>> >>> >> policies for things like JMSXUserId, Timestamps, Expiry, etc >>> >>> >> >>> >>> >> 2. Message body manipulation. (Clebert mentioned perhaps an extension of >>> >>> >> Divert / Transformers?) >>> >>> >> >>> >>> >> 3. Activity tracing for audit tracing and/or triggering other activity >>> >>> >> (extension point at PostOffice and ActiveMQServer ?) >>> >>> >> >>> >>> >> One side benefit might be that Advisory support becomes a plugin vs an >>> >>> >> ingrained feature. Could be handy to have all the advisory logic in one >>> >>> >> place to allow more customization of behavior. >>> >>> >> >>> >>> >> Thoughts? >>> >>> >> >>> >>> >> -Matt Pavlovich >>> >>> >> >>> >>> >> >>> >>> > >>> >>> > >>> >>> >>> >>> -- Clebert Suconic
