Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
MIME-Version: 1.0
In-Reply-To: <VI1PR0901MB0893B8420E788BB5497DDD2ECD3A0@VI1PR0901MB0893.eurprd09.prod.outlook.com>
References: <VI1PR0901MB0893889BC97BE352E449B7CFCD260@VI1PR0901MB0893.eurprd09.prod.outlook.com>
 <CAFitrpTzbBL32ufCjo00GAfux45oM6wQ6Dmbw=ViJROaj=2fGQ@mail.gmail.com>
 <VI1PR0901MB0893A65055D76B19EBB59918CD390@VI1PR0901MB0893.eurprd09.prod.outlook.com>
 <CAFEMS4sgMyMe4K6ayjELe2BYB0YgTWs8zsG+kLb7rAPdZiKhgw@mail.gmail.com>
 <CAGK6+9mAVt69ybrG7dk2fqs79e9Ji2ryjhDWY3B-PwmZ1aza5Q@mail.gmail.com>
 <VI1PR0901MB0893D77868B8494EC7A4FEA2CD390@VI1PR0901MB0893.eurprd09.prod.outlook.com>
 <CACsaS97G_TjE3nqig0Q1w7kHRENXLe4-kFYAW56xvBpp9r1Q=A@mail.gmail.com> <VI1PR0901MB0893B8420E788BB5497DDD2ECD3A0@VI1PR0901MB0893.eurprd09.prod.outlook.com>
From: Rob Godfrey <rob.j.godfrey@gmail.com>
Date: Mon, 20 Mar 2017 12:27:04 +0100
Message-ID: <CACsaS95DQsaKvH7TGh1jVhJMm8vc43+BxkSz0bDSy53pd+Jjwg@mail.gmail.com>
Subject: Re: [Qpid Broker - 6.0.4] Junit testable?
To: "users@qpid.apache.org" <users@qpid.apache.org>
Cc: "keith.wall@gmail.com" <keith.wall@gmail.com>
Content-Type: multipart/alternative; boundary=001a113a2eb48ad869054b27ce18
archived-at: Mon, 20 Mar 2017 11:27:14 -0000

--001a113a2eb48ad869054b27ce18
Content-Type: text/plain; charset=UTF-8

On 20 March 2017 at 11:30, Adel Boutros <Adelboutros@live.com> wrote:

> 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.
>

OK - that part I haven't built yet.  I had been considering generating some
sort of Config objects that can then be serialized into JSON or
something... I might look at this at the weekend.


> 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.
>


OK - that's a slightly different use case to the normal one we have (where
people want to have tests that run against a static configuration of the
broker... not that the people doing the testing will also be using REST on
the production systems to set up their queues etc).


> 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.
>
>
As Keith has already mentioned, this is much easier on trunk than in it is
in the 6.x code.

-- Rob


>
> 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/htm
> l/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
> > >
> > >
> >
>

--001a113a2eb48ad869054b27ce18--