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 <mattr...@gmail.com> 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
