qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Huston <shus...@riverace.com>
Subject Re: We've got an App for that .... Qpid Web Based GUI - and more - just released.
Date Sun, 20 Jan 2013 22:46:58 GMT
I don't understand some of what you said ;-) but this looks FANTASTIC!
I'll be looking at this closer in the coming weeks.


On 1/20/13 11:26 AM, "Fraser Adams" <fraser.adams@blueyonder.co.uk> 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.
>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
>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:
>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 <host>: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
>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,

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message