Hello Frase,

config.js with consoleConnections works like a charm. 

Now it's possible to monitor multiple brokers without explicitly defining qmf 
connections to them by means of GUI.

Great job! Thanks a lot!

Best Regards,
Sergey 

-----Original Message-----
From: Fraser Adams [mailto:fraser.ad...@blueyonder.co.uk] 
Sent: Saturday, February 02, 2013 8:17 PM
To: users@qpid.apache.org
Subject: Qpid GUI config - response for SergeyZhemzhitsky

Hi Sergey,
Since we last spoke I had a think about this and a bit of a play and I've come 
up with what I reckon is quite an elegant and simple approach to this, which 
also "embraces the power of the client side" which follows the spirit of this 
GUI :-)


To explain a bit. As I mentioned in my original response the QpidRestAPI server 
is intended to be a fairly "thin" layer. Conceptually what I was trying to 
achieve was the concept that the *browser* behaves as a proper QMF Console. 
What this means is that if you imagine say a python client like qpid-config 
creating a Qpid Connection then a Console object and using that to get QMF 
Objects that's exactly what I'm getting the browser to do.

In practice it's not "quite" as simple as that given network restrictions in 
the browser, so what actually happens is that when I create a Qpid Connection 
in the browser "under the hood" it does a RESTful PUT to PUT a Qpid Connection 
resource onto the REST Server (in other words when a Connection is created in 
JavaScript that results in a proxy connection getting created on the 
QpidRestAPI) once in place that resource is controlled via RESTful GET/POST and 
eventually DELETE methods invoked via jQuery AJAX calls.

That happens independently for any browser connecting, so although the 
Connection objects have resource "names" on QpidRestAPI they are best thought 
of as "handles" and entirely different to the Connection names on the GUI, 
which are intended to be memorable/friendly names for connections and entirely 
up to the user. The JavaScript Connection class actually creates a UUID for the 
"handle" transparent to the user.


So that's just explaining how the architecture works, but in terms of simple 
config - well as it happens in the JavaScript qmfui.Console class there was a 
variable called consoleConnections which was used to hold the array of 
consoleConnections added in the GUI and this was initialised to hold the 
default.

Just to mess around I made this a public property of qmfui.Console e.g.

     this.consoleConnections = [{name: "default", url: "",
connectionOptions: ""}];

instead of

     var consoleConnections = [{name: "default", url: "",
connectionOptions: ""}];


So why that's significant is it can be used to provide trivially simple 
configuration as ultimately it's just a JSON array, so I added the 
following line to qmf.html in the ui subdirectory (this has to be after 
the line <script src="/qmf-ui/scripts/qmf-ui.js"></script> in the head 
block)

     <script src="/ui/config.js"></script>

and added the file config.js to the ui subdirectory too (same directory 
as the html). In this file I put:


qmfui.Console.consoleConnections = [
     {name: "default", url: "", connectionOptions: ""},
     {name: "localhost", url: "localhost:5672", connectionOptions: ""},
     {name: "wildcard", url: "0.0.0.0:5672", connectionOptions: ""}
];


As you can see it's a fairly straightforward JSON array containing JSON 
objects describing the connections you'd like to start out with.

If you don't want anything other than the default just leave config.js 
empty.

This is really serving config to the client side, but that's where all 
the state is held so it makes a lot more sense than properties on the 
server.


The reason I've put the config.js in the ui subdirectory is because that 
one is "protected" by the authentication. At the moment I've only got 
support for BasicAuthentication so user/passwd are sent clear and be 
aware so to would config.js. If you have sensitive usernames/passwords 
that's something to be aware of if you want to use this config at the 
moment.

For the case of the default URL "" that doesn't get passed to the 
browser so you could configure a broker with a user/pass using 
./QpidRestAPI -a ...... and that info wouldn't be passed to the browser 
because the browser only needs to supply a url of "" to create a 
connection using the default connection URL.

It might not be an issue if you're on a private network, but do bear it 
in mind. Providing a bit more security is on my "todo" list but it 
wasn't top of my priorities initially.


I'll incorporate this stuff into my next release, but as you asked about 
this feature I thought that you might be interested - if you're feeling 
adventurous you could could tweak your own copy of qmf-ui.js - if you 
search for "consoleConnections" in there it's really just a case of 
changing "var " to "this." in front of it then adding the tweak to 
qmf.html and adding the config.js I describe above.

Let me know how you get on...

Best Regards,
Frase



On 29/01/13 08:56, Zhemzhitsky Sergey wrote:
> Hi Fraser,
>
> Amazing GUI! Thanks a lot!
>
> I'm wondering whether there is a possibility to specify all the brokers to 
> connect to in a properties file, i.e.
>
> config.properties
>
> broker.default=guest/guest@host1:5672
> broker.name2=guest/guest@host2:5672
> broker.name3=guest/guest@host3:5672
>
> broker.default.hide.qmf.objects=true
> broker.name2.hide.qmf.objects=false
> broker.name3.hide.qmf.objects=true
>
> So all this brokers will be displayed just after restarting of the GUI under 
> the names specified in the properties file.
>
>
> Best Regards,
> Sergey
>

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


_______________________________________________________
CONFIDENTIALITY NOTICE: This email and any files attached to it may be 
confidential. If you are not the intended recipient you are notified that 
using, copying, distributing or taking any action in reliance on the contents 
of this information is strictly prohibited. If you have received this email in 
error please notify the sender and delete this email. 

Reply via email to