Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
MIME-Version: 1.0
In-Reply-To: <CACHnxzz+Gwfxok4+WP1O9CzCcT-+wmP7AZrd_92ZupjydR4A+A@mail.gmail.com>
References: <2c22bee4-5d67-c764-fe6b-4a5cd2e14999@gmail.com>
 <CAKF+bsrKYUUbn-yQNiNNxE4uizuo9Wq8JYaPFueNDEeXANk_PQ@mail.gmail.com>
 <166f2ace-e11c-2cba-21ff-feeebb775057@gmail.com> <CAKF+bsq=jDwKc0w8YHdc5-sZk2stf9fG4ij-FSBeBJ9aetGTwg@mail.gmail.com>
 <CACHnxzz+Gwfxok4+WP1O9CzCcT-+wmP7AZrd_92ZupjydR4A+A@mail.gmail.com>
From: Clebert Suconic <clebert.suconic@gmail.com>
Date: Tue, 20 Dec 2016 15:08:27 -0500
Message-ID: <CAKF+bspey_EVhyr4s3HzRGkkXT9n=ar94Z7vj89QXPD=eSy0_A@mail.gmail.com>
Subject: Re: [DISCUSS] Artemis plugins ARTEMIS-898
To: "dev@activemq.apache.org" <dev@activemq.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Tue, 20 Dec 2016 20:08:47 -0000

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
<christopher.l.shannon@gmail.com> 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
> <clebert.suconic@gmail.com> 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 <mattrpav@gmail.com> 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 <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
>>>
>>> >>
>>>
>>> >>
>>>
>>> >
>>>
>>> >
>>>
>>>
>>>
>>>


-- 
Clebert Suconic