I don't understand some of what you said ;-) but this looks FANTASTIC! I'll be looking at this closer in the coming weeks. THANK YOU! On 1/20/13 11:26 AM, "Fraser Adams" wrote: >For those of you who follow my postings on the Qpid Mailing List you'll >probably be aware that I've been doing quite a lot with QMF2. > > >I've just made a fairly major uplift to the QMF2 code base. > >https://issues.apache.org/jira/browse/QPID-3675 > > >There are a few bug fixes to the core Java QMF2 implementation, the most >significant being that the ManagementAgent can return multiple partial >responses if there are large numbers of objects, the QMF2 getObjects() >call now caters for that. > >However the most significant uplift is the addition of: >1) A QMF2 REST API Implementation. >2) A JavaScript QMF2 Implementation that uses the REST API as a back end. >3) A fully featured Qpid Management Web GUI that does pretty much >anything you'd need to do to >monitor and manage one or more brokers (it supports connecting to >different brokers). > >The REST and JavaScript QMF2 implementations are fairly complete, the >main thing missing is support for QMF2 Query Subscriptions, which are >supported in the Java API but I've not got round to adding them to REST >& JavaScript versions. > >The JavaScript implementation uses AJAX to talk to the REST API, this is >mainly because that approach is supported on pretty much every browser. >I might look to adding WebSocket support IDC when I've got a bit more >familiarity with WebSockets. > > >The Web GUI works on multiple browsers and is even functional on IE6 >:-), it morphs quite well onto mobile devices and uses GPU accelerated >animations to give a fairly "native app" feel on iPad/iPhone. > >The REST API Server was deliberately designed to have almost no >dependencies. It uses the com.sun.net.httpserver.HttpServer embedded Web >Server that is part of JDK 6 (at least on Sun and OpenJDK) so just >requires the Qpid jars on the classpath. It has been designed to make it >fairly easy to add a Servlet implementation, but that's not been done >yet as the initial goal was to make it fairly dependency free and >embedded. > >The REST API is very RESTful and uses PUT to add Qpid Connections but >there is automatic creation of a "default" resource if one tries to do a >GET so for example doing: > >http://:8080/qpid/connection/default/console/objects/queue > >will retrieve the latest update of the QMF queues as a JSON string, >which will parse into a list of QmfConsoleData objects. The QpidServer >class JavaDoc documents the complete REST API but hopefully the example >above should give the gist (that's the REST equivalent of >getObjects("queue") in case it wasn't obvious). > > >To get up and running all that should be required is the Qpid jars on >the classpath and running ant in the root qmf2 directory. > > >Once compiled cd to bin and do ./QpidRestAPI.sh by default it tries to >bind to the >wildcard address on the host it's running on and port 8080 though this >stuff is configurable. > >Point a browser at :8080 and you should be in business. By default >it will create a default QMF connection to a broker running on the same >host as the QpidRestAPI on port 5672 but the default broker connection >is configurable too. > >Once running you can add QMF2 Console Connections to other brokers and >connect to them via the Web GUI. > >The main limitation at the moment is the authentication. It uses basic >authentication so username/password are sent clear. I'll look to do >something better IDC but I wanted to get it released as it represents >around a years worth of work over weekends. > >the authentication file is in >qmf2/bin/qpid-web/authentication/authentication.properties and has the >traditional >admin=admin >guest=guest > >Obviously you might want to change that :-) it supports dynamic changes >to the file. > >FWIW although the Web GUI doesn't yet have better authentication it >should be possible to configure the QpidRestAPI to use a default >connection to a secure broker. The broker credentials for the default >broker aren't returned to the browser - to use the defaults it just >supplies a broker URL of "". Obviously the broker management statistics >will still be being sent over an unsecure channel but that may not be an >issue in many cases. > > > >It's all released under the Apache Licence and the GUI uses a JavaScript >UI library that I ended up writing as part of this project (called >itablet) which should be reusable in other projects. > > >I hope that this is useful to people, as I say it's taken an awful lot >of effort to put together, so I'd *really* appreciate feedback. > > >I should point out that this is QMF2 based and so it can only talk to >the C++ broker at the moment, however if people are interested and the >feedback is positive I'll look to uplifting the back end to also proxy >to the JMX mechanism used by the Java broker. I must admit that I've not >got any real familiarity with the Java broker, but it ought to be >do-able assuming that the Java broker JMX Management Objects have >similar capabilities to the C++ QMF Management Objects. > >Finally if you point it at a broker less than 0.10 the add/delete >queue/exchange/binding features won't work as they require broker object >create/delete methods that were added in 0.10. > >I've attached a couple of screen shots of a few different pages on a few >different browsers to pique your interest :-) > > >I really hope that the QMF stuff can make it into the main Qpid release >at some point, I did the first Java QMF2 API release over a year ago but >I've not had much feedback, hopefully with the addition of a management >GUI it'll get a bit of traction? > >Best Regards, >Frase > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org