From users-return-7650-apmail-qpid-users-archive=qpid.apache.org@qpid.apache.org Sat Feb 2 16:19:10 2013 Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 56E31E124 for ; Sat, 2 Feb 2013 16:19:10 +0000 (UTC) Received: (qmail 62041 invoked by uid 500); 2 Feb 2013 16:19:10 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 61947 invoked by uid 500); 2 Feb 2013 16:19:07 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 61906 invoked by uid 99); 2 Feb 2013 16:19:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Feb 2013 16:19:05 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of fraser.adams@blueyonder.co.uk designates 81.103.221.52 as permitted sender) Received: from [81.103.221.52] (HELO mtaout04-winn.ispmail.ntl.com) (81.103.221.52) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Feb 2013 16:18:56 +0000 Received: from know-smtpout-1.server.virginmedia.net ([62.254.123.3]) by mtaout04-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20130202161834.TVNQ8801.mtaout04-winn.ispmail.ntl.com@know-smtpout-1.server.virginmedia.net> for ; Sat, 2 Feb 2013 16:18:34 +0000 Received: from [82.33.33.147] (helo=[192.168.1.103]) by know-smtpout-1.server.virginmedia.net with esmtpa (Exim 4.63) (envelope-from ) id 1U1fmN-0006by-7Z for users@qpid.apache.org; Sat, 02 Feb 2013 16:17:24 +0000 Message-ID: <510D3C04.8020607@blueyonder.co.uk> Date: Sat, 02 Feb 2013 16:17:08 +0000 From: Fraser Adams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: users@qpid.apache.org Subject: Qpid GUI config - response for SergeyZhemzhitsky References: <50FC1AAA.5010800@blueyonder.co.uk> <50FE964D.6060708@redhat.com> <1358865462.3647.8.camel@cratus.office.paradigmaxis.pt> <50FEA74D.4080508@redhat.com> <50FEAB65.3040701@redhat.com> <1358867389.3647.16.camel@cratus.office.paradigmaxis.pt> <50FEB5D1.8030307@redhat.com> <50FEE545.90400@blueyonder.co.uk> <1358937684.5466.13.camel@cratus.office.paradigmaxis.pt> <51059D84.4060207@blueyonder.co.uk> <1359372170.3133.13.camel@cratus.office.paradigmaxis.pt> <5106E8E4.1020006@blueyonder.co.uk> <5106F338.2030400@paradigmaxis.pt> <06139A918ACCA041BF46A0F36940C7FA6EB810FE@exch-mbx6.msk.trd.ru> In-Reply-To: <06139A918ACCA041BF46A0F36940C7FA6EB810FE@exch-mbx6.msk.trd.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.1 cv=AUhbpHVS+xhHrj9wLCYAQoYnFLYUZdbP8UM0GmH2jwk= c=1 sm=0 a=D6wcrpBcUpcA:10 a=usVr8rFlXL4A:10 a=3NElcqgl2aoA:10 a=IkcTkHD0fZMA:10 a=cw102yeOOwGH5dIfeU4A:9 a=QEXdDO2ut3YA:10 a=dn-Kqwdv8oIA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 X-Virus-Checked: Checked by ClamAV on apache.org 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 in the head block) 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-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org