Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Received-SPF: pass (nike.apache.org: domain of tabish121@gmail.com designates
 209.85.192.44 as permitted sender)
Message-ID: <550327B5.6010903@gmail.com>
Date: Fri, 13 Mar 2015 14:08:53 -0400
From: Timothy Bish <tabish121@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: dev@activemq.apache.org
Subject: Re: ActiveMQ DSLs
References: <55030CA0.5000408@gmail.com>
In-Reply-To: <55030CA0.5000408@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 03/13/2015 12:13 PM, Jakub Korab wrote:
> Hi All,
>
> In working on a separate project, I found the need to instantiate 
> multiple different ActiveMQ configurations. Rather than writing up a 
> lot of different XML configs or messing around with assembling 
> BrokerService instances, I wrote a DSL that mimics the ActiveMQ config 
> schema via a directed builder pattern, much like Camel. Here's an 
> example:
>
> BrokerContext context = new 
> BrokerContext(ActiveMQBrokers.broker("embeddedBroker").useJmx(false).persistent(false)
>         .transportConnectors()
>             .transportConnector("openwire", "tcp://0.0.0.0:61616").end()
>         .end()
>         .plugins()
>             .simpleAuthenticationPlugin()
>                 .users()
> .authenticationUser("user").password("pass").groups("guests").end()
>                 .end()
>             .end()
>         .end()));
>
> context.start();
> ...
> context.end();
>
> Unlike Camel, the DSL itself defines a model that is used to 
> instantiate a BrokerService. Camel has an intermediate set of VOs 
> (org.apache.camel.model) between the Java DSL and the implementation. 
> I had a go at generating a similar model via JAXB from the ActiveMQ 
> schema, to abstract away the DSL/XBean config, but the generated 
> classes were hideous and I abandoned the approach.
>
> I also developed a testing DSL for JUnit that allows you to spin up 
> these configurations, and rely on the JUnit runner to start up and 
> shut down the broker. The test DSL also allows for the definition of 
> proxies (using the ActiveMQ SocketProxy class) to easily simulate 
> network outages.
>
> A full writeup and source code are available at
>
>     https://github.com/jkorab/activemq-dsls
>
> As it stands, the DSL is a work in progress that supports my own code, 
> but I think it would be useful as something provided by ActiveMQ 
> itself. I would like to contribute what I have written so far, and 
> develop it further (perhaps cleaning up a bunch of ActiveMQ tests to 
> use it in an "eating your own dogfood" way). I was initially thinking 
> that it could be part of activemq-broker in the src/test tree, and 
> once it gets fleshed out, moved to src/main. The set of config options 
> in ActiveMQ is huge, and retrofitting tests would be an ideal way of 
> evolving it and validating that everything works before making it public.
>
> I think that this is something that would be useful, as I have seen 
> ActiveMQ deployments where the broker was defined in Java. This is 
> particularly useful where there are is a broker network with a bunch 
> of network connectors from a broker, each with dynamically or 
> statically included or excluded destinations, used in conjuction with 
> composite destinations to route messages in "just the right way". That 
> sort of thing is much better expressed in code rather than huge slabs 
> of XML.
>
> What do you think? Is this something that would be worthwhile to have 
> in ActiveMQ?
>
> Jakub
>
Cool stuff, definitely seems like something we ought to consider adding.

-- 
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.bish@redhat.com | www.redhat.com
skype: tabish121 | twitter: @tabish121
blog: http://timbish.blogspot.com/