activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Korab <>
Subject Re: ActiveMQ DSLs
Date Sat, 14 Mar 2015 12:12:45 GMT
My view of this is that this sort of thing is useful to about 5-10% of 
users for an actual deployment.

What I have seen out in the field is that there are instances where 
users need to access a single broker, which is their entry point into a 
broader topology. The routing of messages at such a broker tends to 
become selective 
(dynamicallyIncludedDestination/staticallyIncludedDestination etc.). To 
prevent network loops, you may start using composite destinations to 
rewrite messages into queues whose only reason is to be consumed by a 
network connector. As the number of queues increases, so does the amount 
of config. I have seen configs that run into hundreds of lines, with a 
lot of cut and paste.

Allowing someone to define a broker programatically allows you to cut 
down on the repetition, and removes likely misconfigurations. So, I have 
seen instances where people do this, through piecing together a 
BrokerService by hand. The problem with this approach is that it quickly 
becomes unreadable. Syntatic sugar makes it easy to comprehend what 
exactly is going on to anyone maintaining (or just re-reading the code a 
month later), and mimicking the XML config means it's easy to apply the 

So the JSON or YAML thing doesn't address this use case - it's just 
another form of markup. It doesn't mean that it couldn't be done. The 
hurdle is that ActiveMQ doesn't actually have an intermediate config 
model - the XBean annotations sit over the implementation classes. If 
such a model existed you could apply a set of classes that overlay YAML, 
JSON bindings or whatever language DSLs over the top. What would make 
this really neat would be that you could pull out the model that 
configured a running broker, and redisplay it in XML via JMX a-la Camel.


On 13/03/15 20:07, Hadrian Zbarcea wrote:
> 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.
> Hadrian
> 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