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 > > >> > > >> > > > > > > > > > >
