You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Fraser Adams <fr...@blueyonder.co.uk> on 2013/02/02 17:17:08 UTC
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
RE: Qpid GUI config - response for SergeyZhemzhitsky
Posted by Zhemzhitsky Sergey <Se...@sberbank-cib.ru>.
Hi Frase,
I have no chance to test the GUI with mobile browser yet, but screenshots you attached are really cool.
I suppose it's the best web-based qpid management tool by the time!
Best Regards,
Sergey Zhemzhitsky
Phone. +7 495 2580500 ext. 1246
-----Original Message-----
From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
Sent: Monday, February 04, 2013 11:07 PM
To: users@qpid.apache.org
Subject: Re: Qpid GUI config - response for SergeyZhemzhitsky
Hey wow Sergey,
I'm so pleased that you gave it a whirl :-) I guess that the instructions were clear enough after all, cool!
Hopefully the code is fairly OK to follow. It looks a bit daunting at first, but it's actually fairly well structured (well I think so :-)) - basically there's a Singleton class for each core page and they are mostly pretty self contained. Any data passed between "pages" gets attached to the query part of the url and the core navigation is done via url fragments/hash which map nicely to DIV ids.
I've tried to put in a decent amount of comments in a JavaDoc style, of course you can never have too many comments, but hopefully what's there is useful. I'm toying with the idea of adding a JavaScript minimiser on the server to minimise "on the fly" so it's not so verbose when sent over the wire, but that's a "nice to have" for now.
I actually quite like that approach to implementing the config, it was one of those "lightbulb" moments to do something pretty useful trivially easily.
One thing to be aware of is that clicking between the different connections isn't as reliable as it ought to be in v1.1 :-( It was a feature I added a bit late in the day and to be honest I also rushed in the feature to disable QMF Events (and use timed polling instead).
Having added the config.js I had a lot more connections to play with and noticed that sometimes a connection would flag up Broker Disconnected and not reconnect. I also noticed that if I randomly clicked between them quickly I may get extra connections staying active and occasionally they haven't expired.
I spent the weekend going through the JavaScript and REST object lifecycle and adding a lot more defensive code. I think that I've sorted that stuff out now so hopefully the next release should be a little less flaky. To be fair I've always been able to connect, but sometimes I've had to click back and forth between connections, which is a bit rubbish.
Anyway hopefully that's another bug shot.
Thanks again for playing with the GUI and for trying out the config.js I hope that you are liking it. Niggles aside I'm mostly pretty pleased with it. I really hope that it can be used to "show off" Qpid to "management types". Have you been able to try it with a mobile browser yet? It looks pretty nice on an iPhone :-)
Cheers,
Frase
On 04/02/13 12:53, Zhemzhitsky Sergey wrote:
> 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.adams@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-unsubscribe@qpid.apache.org For
> additional commands, e-mail: users-help@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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org
Re: Qpid GUI config - response for SergeyZhemzhitsky
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hey wow Sergey,
I'm so pleased that you gave it a whirl :-) I guess that the
instructions were clear enough after all, cool!
Hopefully the code is fairly OK to follow. It looks a bit daunting at
first, but it's actually fairly well structured (well I think so :-)) -
basically there's a Singleton class for each core page and they are
mostly pretty self contained. Any data passed between "pages" gets
attached to the query part of the url and the core navigation is done
via url fragments/hash which map nicely to DIV ids.
I've tried to put in a decent amount of comments in a JavaDoc style, of
course you can never have too many comments, but hopefully what's there
is useful. I'm toying with the idea of adding a JavaScript minimiser on
the server to minimise "on the fly" so it's not so verbose when sent
over the wire, but that's a "nice to have" for now.
I actually quite like that approach to implementing the config, it was
one of those "lightbulb" moments to do something pretty useful trivially
easily.
One thing to be aware of is that clicking between the different
connections isn't as reliable as it ought to be in v1.1 :-( It was a
feature I added a bit late in the day and to be honest I also rushed in
the feature to disable QMF Events (and use timed polling instead).
Having added the config.js I had a lot more connections to play with and
noticed that sometimes a connection would flag up Broker Disconnected
and not reconnect. I also noticed that if I randomly clicked between
them quickly I may get extra connections staying active and occasionally
they haven't expired.
I spent the weekend going through the JavaScript and REST object
lifecycle and adding a lot more defensive code. I think that I've sorted
that stuff out now so hopefully the next release should be a little less
flaky. To be fair I've always been able to connect, but sometimes I've
had to click back and forth between connections, which is a bit rubbish.
Anyway hopefully that's another bug shot.
Thanks again for playing with the GUI and for trying out the config.js I
hope that you are liking it. Niggles aside I'm mostly pretty pleased
with it. I really hope that it can be used to "show off" Qpid to
"management types". Have you been able to try it with a mobile browser
yet? It looks pretty nice on an iPhone :-)
Cheers,
Frase
On 04/02/13 12:53, Zhemzhitsky Sergey wrote:
> 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.adams@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
RE: Qpid GUI config - response for SergeyZhemzhitsky
Posted by Zhemzhitsky Sergey <Se...@sberbank-cib.ru>.
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.adams@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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@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.