activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Korab <>
Subject Re: ActiveMQ DSLs
Date Tue, 17 Mar 2015 10:59:32 GMT
Just taking a look through the source tree, given that all the tests are 
in activemq-unit-tests, it doesn't make a structural difference. Keeping 
it external might make sense as it would be an optional extra.

I also have a test DSL as a sub-project of my source tree that uses 
JUnit 4.11 (same version as used by ActiveMQ) @Rule annotations, which 
get the test runner to manage the lifecycle of the DSL-defined broker 
(as opposed to writing the same setUp() and tearDown() methods all the 
time). It allows lookups of transport connector URIs for easy 
ConnectionFactory instantiation, and also does transparent network 
proxying via a SocketProxy.

|public class MyEmbeddedBrokerTest {
     public ProxiedBrokerResource broker = new BrokerResource(
                     .transportConnector("openwire", "tcp://").end()
                     .transportConnector("stomp", "stomp://").end()
             .withProxied("openwire").port(10000); // port to be proxied is looked up by name
             // you can define multiple proxies for the one broker!

     public void testNetworkOutages() {
         ConnectionFactory cf =
             new ActiveMQConnectionFactory(
                 "failover:(" + broker.getTcpConnectionUri("openwire") + ")"); // returns
proxied port 10000
         // ...
         SocketProxy socketProxy = broker.getProxy("openwire");
         socketProxy.close(); // network goes down
         // ...
         socketProxy.reopen(); // network comes back up

I would like to drop it in to an activemq-test-dsl project - that would 
allow its use in unit tests, as well as by anyone external who would 
like to make use of it. Does that sound good?

I think that the general consensus is to go ahead. How do I go about 
doing this? Should I log in in Jira, and issue a pull request from a git 


On 17/03/15 10:30, Dejan Bosanac wrote:
> That’s fine by me as well. It’s just that I don’t see it as much of a
> burden on activemq-broker. It really is just a couple of classes in it’s
> own package which can be used to configure and run the broker from Java. If
> it’s a separate module, than we need to make sure we include it
> activemq-all, activemq-osgi, etc, and add it as a dependency to all modules
> that want to use it for testing. So in the end it will be more complicated.
> But whatever folks prefer is fine by me.
> Regards
> --
> Dejan Bosanac
> ----------------------
> Red Hat, Inc.
> Twitter: @dejanb
> Blog:
> ActiveMQ in Action:
> On Tue, Mar 17, 2015 at 11:17 AM, Hadrian Zbarcea <>
> wrote:
>> How about a separate jar that could be used in conjunction with
>> activemq-broker? In time start moving 'nice to have' things from
>> activemq-broker into this other jar?
>> Hadrian
>> On 03/17/2015 05:57 AM, Dejan Bosanac wrote:
>>> IMHO it should be enough to just put these classes in the new package
>>> (something like inside the
>>> activemq-broker
>>> module.
>>> Regards
>>> --
>>> Dejan Bosanac
>>> ----------------------
>>> Red Hat, Inc.
>>> Twitter: @dejanb
>>> Blog:
>>> ActiveMQ in Action:
>>> On Tue, Mar 17, 2015 at 12:26 AM, artnaseef <> wrote:
>>>   That's an interesting use-case, and I see the value there.
>>>> Would this be a new, separate artifact or a change to an existing one?
>>>> Art
>>>> P.S. apologies for confusion on my earlier post - using nabble's "raw"
>>>> content did indeed cause the content of the post to get stripped in email
>>>> somehow.
>>>> --
>>>> View this message in context:
>>>> tp4693171p4693332.html
>>>> Sent from the ActiveMQ - Dev mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message