I like this idea. ActiveMQ is a pretty complicated piece of software with all of its configuration options. Writing unit/integration tests that try to capture some edge case, or odd configuration combination, does end up getting hairy, duplicative, and difficult to understand and maintain. A DSL like this could help reduce some of that noise. At the very minimum we should get this/something like this into the testing code base and use that as a way to refine/improve the DSL API and our unit tests.
On Fri, Mar 13, 2015 at 9:13 AM, Jakub Korab <[email protected]> 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 > -- *Christian Posta* twitter: @christianposta http://www.christianposta.com/blog http://fabric8.io
