Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of jakub.korab.lists@gmail.com
 designates 209.85.212.182 as permitted sender)
Message-ID: <55030CA0.5000408@gmail.com>
Date: Fri, 13 Mar 2015 16:13:20 +0000
From: Jakub Korab <jakub.korab.lists@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: dev@activemq.apache.org
Subject: ActiveMQ DSLs
Content-Type: multipart/alternative;
 boundary="------------020106060603000209020501"

--------------020106060603000209020501
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------020106060603000209020501--