qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adel Boutros <Adelbout...@live.com>
Subject Re: [Qpid Broker - 6.0.4] Junit testable?
Date Fri, 17 Mar 2017 15:09:44 GMT
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.


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.



From: Dan Langford <danlangford@gmail.com>
Sent: Friday, March 17, 2017 3:46:46 PM
To: keith.wall@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.wall@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 <Adelboutros@live.com> wrote:
> > Hello Robbie,
> >
> > Can you please provide a simple example?
> >
> > Regards,
> > Adel
> > ________________________________
> > From: Robbie Gemmell <robbie.gemmell@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 <Adelboutros@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-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

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