[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    Re: [DISCUSS] ARTEMIS-898 plugin support
From:       Christopher Shannon <christopher.l.shannon () gmail ! com>
Date:       2017-04-19 15:54:16
Message-ID: CACHnxzxnz0n7xCgE0c=fjHfgRzO4YK-XHeVxEqNmm1=xjOBt=g () mail ! gmail ! com
[Download RAW message or body]


As a follow up, I'm working on testing out the plugin API by seeing if it
is possible to implement some of the custom plugins I have in 5.x.  I just
want to make sure that all of the methods make sense before doing the PR.
I will most likely end up pushing a PR for this sometime next week.

On Thu, Apr 13, 2017 at 3:39 PM, Christopher Shannon <
christopher.l.shannon@gmail.com> wrote:

> Cool, thanks for taking a look.  I will continue on with the changes (and
> tests) and I will submit a PR when I think it's ready and we can continue
> the discussion then.
>
> On Thu, Apr 13, 2017 at 2:25 PM, Clebert Suconic <
> clebert.suconic@gmail.com> wrote:
>
>> It looks good.. I like it...
>>
>>
>> I have commented on your commit with a few improvements.. main one is
>> to have context about the event.. like queue name when a message is
>> acked).. (or maybe consumer instead)...
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Apr 13, 2017 at 10:28 AM, Christopher Shannon
>> <christopher.l.shannon@gmail.com> wrote:
>> > Hi Everyone,
>> >
>> > So I started to implement a framework for doing plugin support but
>> before I
>> > get to far I wanted to get everyone's opinion.  My working commit is
>> here:
>> > https://github.com/cshannon/activemq-artemis/commit/76002043
>> 55796405c9482ae8c4fe84d8fbe9b44b
>> >
>> > My strategy I'm trying is to just have one interface that a user can
>> > implement to add functionality. Multiple plugins can be chained
>> together by
>> > registering them on the ActiveMQServer.  The chaining is done by just
>> > keeping them in a list so they will be executed in order to keep it
>> simple.
>> > (this is different from 5.x where it uses a delegation pattern to chain
>> > plugins).  The approach is also a bit different than 5.x in that the
>> core
>> > functionality of the broker still wont' be implemented in a Broker
>> plugin.
>> > The plugins will just be executed before/after certain hooks in the
>> broker.
>> >
>> > There is still a lot of work to do and what I have is by no means
>> complete,
>> > methods need to be added/modified and there are no tests or anything yet
>> > but I wanted to see what others thought about this approach before
>> > continuing as there are multiple ways we could approach adding plugin
>> > support.
>>
>>
>>
>> --
>> Clebert Suconic
>>
>
>


[prev in list] [next in list] [prev in thread] [next in thread]