On 20 March 2017 at 11:30, Adel Boutros <[email protected]> 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 <[email protected]> > Sent: Monday, March 20, 2017 11:10:11 AM > To: [email protected]; [email protected] > Subject: Re: [Qpid Broker - 6.0.4] Junit testable? > > 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/htm > l/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] > > > > > > > > >
