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 Mon, 20 Mar 2017 10:30:03 GMT
Hello Rob,


We have many types of testing. Some of them do not require testing administration. So queues
could be static at the start of the tests.

In that case, loading JSON from memory would solve the issue for these tests.

However, we would need to wrap this in Java to allow the users writing tests to configure
the queues without really knowing the content of the JSON. We assume our users will only configure
the brokers via Java or REST so they shouldn't know how the broker actually configures the
queues behind the scene.


We have also another alternative as we have developed internally a Java API to contact the
REST management of the broker, all we actually need now is a proper way to get the dynamic
ports.


Regards,

Adel

________________________________
From: Rob Godfrey <rob.j.godfrey@gmail.com>
Sent: Monday, March 20, 2017 11:10:11 AM
To: keith.wall@gmail.com; users@qpid.apache.org
Subject: Re: [Qpid Broker - 6.0.4] Junit testable?

On Fri, 17 Mar 2017 at 16:10, Adel Boutros <Adelboutros@live.com> 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 <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
> >
> >
>

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