On Fri, 17 Mar 2017 at 16:10, Adel Boutros <[email protected]> wrote:
> 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. Hi Adel... do you really need a way to dynamically configure the embedded broker after it has started, or do you just need a way to inject configuration into the embedded broker before it starts (and without requiring a config file to do so)? I have some code sitting on my laptop which allows for a broker to be started with in memory configuration provided in the form of a JSON String... would that sort of solution work for you? -- Rob > > > > Regards, > > Adel > > ________________________________ > From: Dan Langford <[email protected]> > Sent: Friday, March 17, 2017 3:46:46 PM > To: [email protected]; [email protected] > 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 <[email protected]> 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 <[email protected]> wrote: > > > Hello Robbie, > > > > > > Can you please provide a simple example? > > > > > > Regards, > > > Adel > > > ________________________________ > > > From: Robbie Gemmell <[email protected]> > > > Sent: Friday, March 17, 2017 12:57:59 PM > > > To: [email protected] > > > Subject: Re: [Qpid Broker - 6.0.4] Junit testable? > > > > > > On 16 March 2017 at 18:01, Adel Boutros <[email protected]> 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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
