activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: ActiveMQ DSLs
Date Fri, 13 Mar 2015 20:07:54 GMT
Good job, but I don't think it's a good idea. Sure, interesting 
syntactic sugar, but what problem does it solve? Who would use it? Json 
or YAML would be way more interesting imho.


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

View raw message