Indeed, most users will most probably inject a JMS connection using Spring annotations. So testing it against an easy to embedd broker would be highly appreciated because Spring already provides a lot of helpers in testing.
The problem is that each broker respects the specifications the way it say it fit. We had issues with ActiveMQ when configuring topic linked to queues with advanced filtering. This is why embeddable broker should be as close as possible to the production broker to avoid skipping some bugs or unsupported cases. @Keith, Indeed we could configure queues using REST but then again we need 2 things: * Know the port * Develop a Java like API for rest operations (Not all users knows the REST calls of the broker This is why I was saying the Qpid Broker is not very friendly to use with JMS. I will give a look at the classes you mentioned. Regards, Adel ________________________________ From: Dan Langford <danlangf...@gmail.com> Sent: Friday, March 17, 2017 3:46:46 PM To: keith.w...@gmail.com; users@qpid.apache.org Subject: Re: [Qpid Broker - 6.0.4] Junit testable? You already mentioned HornetQ I would also toss out there ActiveMQ as one that is fantastic at embedding. In my Java projects I code to JMS and in Unit tests I mock out JMS apis because I am just testing MY code. Sometimes it's just easier or a more thorough test to include a broker especially since so much config is moving into Java code these days (spring JMS annotations) and for those I use ActiveMQ embedded. Once I get up to integration type tests we have all of our code tests against a few non-prod Qpid servers we have. We actually have Dev, Test, Stage, Load lanes before getting up into prod. That's probably more lanes than most people need but we have 80-100 little tiny applications that we are regularly working on so those lanes help us manage their progression towards prod. Maybe if you mocked JMS, used an embedded broker that implements AMQP, and then set up a Staging Qpid server that would give you the confidence you need to advance to Production On Fri, Mar 17, 2017 at 8:27 AM Keith W <keith.w...@gmail.com> wrote: > Hi Adel > > There is a recognition that the embed-ability of the Qpid Broker for > Java is not what it should be. We have been making incremental > improvements with each major release but things still aren't ideal > state. > > For the dynamically bound port number, QPID-7597 changes the Broker so > that it is available from the model: Port#getBoundPort(). This will > be part of the next major release. As things stand in 6.0, > unfortunately, there is no clean way to discover the actual bound > port. The best you could do it scrape the log, or intercept the event > logging so pull out the bound port number for AMQP and HTTP, neither > of which are clean I know. The classes to look at are: > org.apache.qpid.server.Broker, > org.apache.qpid.test.utils.QpidBrokerTestCase, > org.apache.qpid.test.utils.InternalBrokerHolder > > For the creation of queues/exchanges, I suggest using the REST API to > create the objects. This is a public API and will be maintained going > forwards. There is REST API summary documentation in the docbook. > > > http://qpid.apache.org/releases/qpid-java-6.0.6/java-broker/book/Java-Broker-Management-Channel-REST-API.html > > There is some online documentation for the REST API available from the > Web Management Console (API link, menu at top right). Firebug within > Firefox has a neat feature to give you a cURL command line for network > requests that have been sent by the browser. You can use this as a > quick way to get a curl command line for an action corresponding you > have just performed interactively. The API is pretty simple. > > The next major release (v7.0) will include support for AMQP > Management. This will allow you to fully manage the Broker from an > AMQP messaging connection. You will be able to use this to fully > configure the Broker from say, a JMS connection. I expect this will > become our recommendation. > > Hope this helps. > > > > On 17 March 2017 at 12:41, Adel Boutros <adelbout...@live.com> wrote: > > Hello Robbie, > > > > Can you please provide a simple example? > > > > Regards, > > Adel > > ________________________________ > > From: Robbie Gemmell <robbie.gemm...@gmail.com> > > Sent: Friday, March 17, 2017 12:57:59 PM > > To: users@qpid.apache.org > > Subject: Re: [Qpid Broker - 6.0.4] Junit testable? > > > > On 16 March 2017 at 18:01, Adel Boutros <adelbout...@live.com> wrote: > >> Hello, > >> > >> > >> As we are currently deploying a messaging solution based on the Java > Broker, we have tried to start a broker from a Junit test and it is not > very straightforward as the configuration part is a bit difficult. Of > course here we are talking about Component Based Testing and Integration > Testing to allow clients to test their code before deploying it. > >> > >> > >> Some of the pain points when using org.apache.qpid.server.Broker: > >> > >> * If port 0 is specified, I have no way to get the actual port > allocated > >> * I need a json config file to configure queues, topics (There is > no Java Api for it directly) > >> > > > > It might not be as easy as would be desired, but the brokers own test > > suite creates queues at runtime (using its HTTP or AMQP management > > support) and as far as I know also starts brokers on 'port 0' these > > days. Perhaps something to look at. > > > >> Another team had tested HornetQ[1] which seems to be more adapted to > embedded testing. However as our production broker will be Qpid Java > Broker, we would like our tests to be as close as possible to production. > >> > >> So my questions are: > >> > >> * Is there currently a way to use an embedded Java Broker easily > configurable in a Junit test? > >> * If not, what would be required to provide such easibility? > >> > >> [1]: > http://docs.jboss.org/hornetq/2.2.5.Final/user-manual/en/html/embedding-hornetq.html > >> > >> Regards, > >> Adel > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
