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 {
@Rule
public ProxiedBrokerResource broker = new BrokerResource(
ActiveMQBrokers.broker("embeddedBroker").useJmx(false).persistent(false)
.transportConnectors()
.transportConnector("openwire", "tcp://0.0.0.0:61616").end()
.transportConnector("stomp", "stomp://0.0.0.0:61618").end()
.end())
.withProxied("openwire").port(10000); // port to be proxied is
looked up by name
// you can define multiple proxies for the one broker!
@Test
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
branch?
Jakub
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.
[email protected]
Twitter: @dejanb
Blog: http://sensatic.net
ActiveMQ in Action: http://www.manning.com/snyder/
On Tue, Mar 17, 2015 at 11:17 AM, Hadrian Zbarcea <[email protected]>
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 org.apache.activemq.broker.dsl) inside the
activemq-broker
module.
Regards
--
Dejan Bosanac
----------------------
Red Hat, Inc.
[email protected]
Twitter: @dejanb
Blog: http://sensatic.net
ActiveMQ in Action: http://www.manning.com/snyder/
On Tue, Mar 17, 2015 at 12:26 AM, artnaseef <[email protected]> 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:
http://activemq.2283324.n4.nabble.com/ActiveMQ-DSLs-
tp4693171p4693332.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
