Thanks Frase, I read and followed along through your explanation and was able to browse various objects and finally create a queue via the REST API backed by the C++ broker using only curl (yay!). Hopefully I can use the interface to create one dynamically with the delete on close attribute. I'll give that a go tomorrow!
On Thu, Jan 23, 2014 at 6:54 PM, Fraser Adams <fraser.ad...@blueyonder.co.uk > wrote: > Hey Davin, > Robbie has hit the nail on the head. One somewhat unfortunate thing that > you probably ought to be aware of is that the management and monitoring for > the Qpid C++ and Java Brokers got somewhat erm "fragmented" for various > reasons back in the mists of time. > > The C++ Broker uses Qpid Management Framework (QMF), but that has had an > interesting evolution and at some point in history QMFv1 migrated to QMFv2 > which caused issues for the Java Broker and they ended up going down a > different path. > > I primarily use the C++ broker, but conversely my team mainly use Java, so > I started out doing a Java implementation of the QMF2 API without knowing > much of that background. There was a bit of comedy 'cause the Qpid Java > guys didn't take a lot of notice of what I was doing 'cause it was QMF and > the C++ guys didn't really notice 'cause it was Java :-D I was a bit in no > mans land really :-/ > > It wasn't really until I put the GUI together that anyone really noticed > and the penny dropped. > > So as Robbie says the REST API that I put together is *actually* a REST > binding for QMF2 and (apart from being a REST API) doesn't bear too much > relationship to the Java Broker's REST interface (for most of history we > were largely unaware of what each other was up to). > > It's a far from ideal position and Rob, Gordon, Robbie and I have chatted > a fair bit about the need to get a more cohesive view. Ultimately the right > answer will be to adopt the AMQP Management Specification across the board, > though that's likely to be some way off (I certainly need to find some time > to properly get my head around it). > > By way of "making a stand for the unity of Qpid Brokers :-)" I put > together a QMF2 plugin for the Java Broker, it was one of those things that > one does "on principle" - really it was as much as anything a statement to > say "really guys it *is* actually possible to provide a cohesive view". One > thing to bear in mind with the Java Broker QMF plugin is that I've tried > fairly hard to map as much as possible from the Java Broker internal > Management Model to QMF Management Objects, but there are differences in > the Management Models, so there are certainly more itty bitty things that > can be controlled by the Java Broker's native management interface than via > QMF (mainly 'cause Robbie keeps adding features ;->) but OTOH pretty much > anything you can do with qpid-config will work with both the C++ and Java > Brokers. > > So to get back to the QMF REST API, the best place to look is the JavaDoc > (yes really, there is actually a ton of JavaDoc for this stuff) > start in <qpid>/tools/src/java/docs/api/index.html > Then look for package org.apache.qpid.restapi and class QpidServer > > To get you started if you do (assuming the same host and port as below): > http://127.0.0.1:8080/qpid/connection/default/console/objects/queue > > You will retrieve a list of all of the QMF Queue Management Objects in the > form of a JSON list (you can do it in a browser too) > http://127.0.0.1:8080/qpid/connection/default/console/objects/exchangewill > retrieve the exchanges > http://127.0.0.1:8080/qpid/connection/default/console/objects/connectionwill > retrieve the connections > and so on. > > the <default> bit is a "convenience", so this is a "true" REST API that > mirrors the QMF API pretty closely so you really ought to first PUT a QMF > Console Connection before you do anything else, but of course PUT is a pain > from a browser, so if you specify "default" for the connection part of the > URI the API transparently creates (or uses an already created) default QMF > Console instance. > > The GUI actually has a JavaScript class that provides a JavaScript > implementation of the QMF2 API, which is backed by the REST API, so the GUI > is generally abstracted from the REST API, there's a factory method for > that which does the HTTP PUT "under the hood" > > You can also use POST in order to invoke QMF methods (for adding/deleting > queues etc.). > To be honest I'm a bit rusty - I tend to use the GUI or at worse the > JavaScript wrapper which abstracts the detail, > and I've not done it "the hard way" for the best part of 15 months, so the > following is pulled out from the code. > > The POST syntax is: > > POST: <host>:<port>/qpid/connection/<name>/object/<ObjectId> > HTTP body: {"_method_name":<method>,"_arguments":<inArgs>} > <method>: A string containing the QMF2 method name e.g. > "getLogLevel", "setLogLevel", "create", "delete". > <inArgs>: A JSON string containing the method arguments e.g. > {"level":"debug+:Broker"} for setLogLevel. > HTTP response: A JSON string containing the response e.g. > {"level":"notice+"} for getLogLevel (may be empty). > > This method invokes the QMF2 method <method> with arguments <inArgs> > on the object <ObjectId> > > And it works like QMF, so what you'd first need to do is to recover the > Broker Management Object > http://127.0.0.1:8080/qpid/connection/default/console/objects/broker > > You need to do this because the majority of the QMF CRUD methods are > applied on the Broker Management Object, > having done this you'd need to do a POST as above (using the ObjectId from > your own Broker Object) > POST http://127.0.0.1:8080/qpid/connection/default/object/@0@ > org.apache.qpid.broker:broker:amqp-broker > And in the HTTP body you need a JSON string. > > To Add a queue I *think* that the JSON body goes something like this (for > your davin_test2 queue): > > { > "_method_name":"create", > "_arguments": {"type": "queue", "name": "davin_test2", "properties": > {"durable": true}} > } > > Clearly this isn't something that one would *generally* do "by hand". > > I've just done: > > curl -X POST -u admin:admin -d '{"_method_name":"create","_arguments": > {"type": "queue", "name": "davin_test2", "properties": {"durable": true}}}' > http://127.0.0.1:8080/qpid/connection/default/object/@0@ > org.apache.qpid.broker:broker:amqp-broker > > On my system and it created a queue called "davin_test2", so I think what > I've just said is accurate, yay!! > > > The available properties for Queues and exchanges isn't brilliantly > documented in the QMF Management Schema > (or anywhere really) and I kind of "reverse engineered" them, looking > through the GUI code (qmf-ui.js in qmfui.AddQueue method) > I can see: > qpid.max_size > qpid.max_count > qpid.flow_stop_size > qpid.flow_stop_count > qpid.flow_resume_size > qpid.flow_resume_count > durable > qpid.file_size > qpid.file_count > qpid.policy_type > qpid.last_value_queue > qpid.last_value_queue_no_browse > qpid.queue_event_generation > alternate-exchange > > If you look in the qpid-config code I think you'd come across these too. > > I've *probably* just made your head explode, so I'd better stop there, > *hopefully* this is helpful and useful background. > > Best regards, > Frase > > P.S. Glad that you like the QMF GUI - it looks pretty nice on an iOS > device, it uses CSS3 animations so the transitions are GPU accelerated. > > > On 23/01/14 19:42, Robbie Gemmell wrote: > >> On 23 January 2014 19:27, Shearer, Davin <dshea...@novetta.com> wrote: >> >> >>> [davin@laptop24 qpid]$ curl -X GET -u admin:admin >>> http://127.0.0.1:8080/rest/queue/davin_test >>> 404 Not Found: File /rest/queue/davin_test not found.[davin@laptop24qpid >>> ]$ >>> >>> Darn, that didn't work... can we put new queues? >>> >>> [davin@laptop24 qpid]$ curl -X PUT -u admin:admin -d '{"durable":true}' >>> http://127.0.0.1:8080/rest/queue/default/davin_test2 >>> 405 Bad Method.[davin@laptop24 qpid]$ >>> >>> What am I missing? >>> >>> Those URLs look a lot like ones that would be used against the REST API >> from the Java brokers management-http plugin. The URLs/payloads used by >> the >> 'QMF REST API' from the tools Fraser put together aren't likely to be that >> similar to them. >> >> I'll now have to defer to someone who can tell you what they would be >> like... >> >> Robbie >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > > -- Davin Shearer
