activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <>
Subject Re: ActiveMQ DSLs
Date Fri, 13 Mar 2015 18:08:53 GMT
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("embeddedBroker").useJmx(false).persistent(false)
>         .transportConnectors()
>             .transportConnector("openwire", "tcp://").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
> 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. |
skype: tabish121 | twitter: @tabish121

View raw message