Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Subject: Re: [DISCUSS] Artemis plugins ARTEMIS-898
To: dev@activemq.apache.org
References: <2c22bee4-5d67-c764-fe6b-4a5cd2e14999@gmail.com>
 <CAKF+bsrKYUUbn-yQNiNNxE4uizuo9Wq8JYaPFueNDEeXANk_PQ@mail.gmail.com>
From: Matt Pavlovich <mattrpav@gmail.com>
Message-ID: <166f2ace-e11c-2cba-21ff-feeebb775057@gmail.com>
Date: Tue, 20 Dec 2016 10:44:07 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CAKF+bsrKYUUbn-yQNiNNxE4uizuo9Wq8JYaPFueNDEeXANk_PQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Tue, 20 Dec 2016 16:44:28 -0000

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