10:52 a.m.
Hey Guys.
I missed last comment on related PR, hence I did not start this thread.
Currently JConsole plugin does something like:
if(as7Remoting){
//use
} else {
//discard connection
// try to connect on hardcoded values locahost:9990
}
https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jbos...
Ive propesed a change to use existing connection to query for proper IP/port pair of
management interface and than attempt to use cmdContext.connect. However it has been
deemed as unfit fix - even though it just addapts IP/port rather than make plugin always
use localhost:9990.
Darran commented on this at some point:
"However as I have said elsehwere I think this is attempting to fix a
'feature' that should not exist in it's current form"
Trick is that this "feature" is there, its faulty, but if its removed, it breaks
backward compatibility.
Also:
Where jconsole is connected to the process locally I suggest two alternatives: -
- Add the CLI tab but with a clear message stating why the CLI is not currently
available, potentially add an 'Establish Connection' button to the tab with the
capability to prompt for a username and password if required and make use of the
discovered address.
-Add an MBean that can handle management ops, the CLI integration can use that MBean
regardless of the connection method and would not require the establishment of additional
connections.
So, any comments/suggestions?
3:16 p.m.
I can't find the PR you are referring to and I'm not sure I fully
understand what the problem is.
However, I can tell you that the original goal was to make this work
just like 'jboss-cli -c' where if you don't specify anything it will try
to connect using our best guess of localhost:9990. If you can make that
smarter I don't see how it breaks backward compatibility. It sounds to
me like a good enhancement.
But Darran's objection may have something to do with what happens in a
domain environment. It's possible to connect jconsole to a server
instance that is not the domain controller. In that case you can't
(shouldn't?) connect CLI to it. So automatic discovery might discover
something that is bogus from a CLI point of view.
Stan
On 8/5/2013 4:52 AM, Bartosz Baranowski wrote:
Hey Guys.
I missed last comment on related PR, hence I did not start this thread.
Currently JConsole plugin does something like:
if(as7Remoting){
//use
} else {
//discard connection
// try to connect on hardcoded values locahost:9990
}
https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jbos...
Ive propesed a change to use existing connection to query for proper IP/port pair of
management interface and than attempt to use cmdContext.connect. However it has been
deemed as unfit fix - even though it just addapts IP/port rather than make plugin always
use localhost:9990.
Darran commented on this at some point:
"However as I have said elsehwere I think this is attempting to fix a
'feature' that should not exist in it's current form"
Trick is that this "feature" is there, its faulty, but if its removed, it
breaks backward compatibility.
Also:
Where jconsole is connected to the process locally I suggest two alternatives: -
- Add the CLI tab but with a clear message stating why the CLI is not currently
available, potentially add an 'Establish Connection' button to the tab with the
capability to prompt for a username and password if required and make use of the
discovered address.
-Add an MBean that can handle management ops, the CLI integration can use that MBean
regardless of the connection method and would not require the establishment of additional
connections.
So, any comments/suggestions?
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:34 p.m.
It's this PR https://github.com/wildfly/wildfly/pull/4662 (which we
closed pending discussion).
-Jaikiran
On Monday 05 August 2013 06:46 PM, ssilvert(a)redhat.com wrote:
I can't find the PR you are referring to and I'm not sure I
fully
understand what the problem is.
However, I can tell you that the original goal was to make this work
just like 'jboss-cli -c' where if you don't specify anything it will try
to connect using our best guess of localhost:9990. If you can make that
smarter I don't see how it breaks backward compatibility. It sounds to
me like a good enhancement.
But Darran's objection may have something to do with what happens in a
domain environment. It's possible to connect jconsole to a server
instance that is not the domain controller. In that case you can't
(shouldn't?) connect CLI to it. So automatic discovery might discover
something that is bogus from a CLI point of view.
Stan
On 8/5/2013 4:52 AM, Bartosz Baranowski wrote:
> Hey Guys.
>
> I missed last comment on related PR, hence I did not start this thread.
>
> Currently JConsole plugin does something like:
>
> if(as7Remoting){
> //use
> } else {
> //discard connection
> // try to connect on hardcoded values locahost:9990
> }
>
>
https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jbos...
>
> Ive propesed a change to use existing connection to query for proper IP/port pair of
management interface and than attempt to use cmdContext.connect. However it has been
deemed as unfit fix - even though it just addapts IP/port rather than make plugin always
use localhost:9990.
>
>
> Darran commented on this at some point:
>
> "However as I have said elsehwere I think this is attempting to fix a
'feature' that should not exist in it's current form"
> Trick is that this "feature" is there, its faulty, but if its removed, it
breaks backward compatibility.
>
> Also:
>
> Where jconsole is connected to the process locally I suggest two alternatives: -
> - Add the CLI tab but with a clear message stating why the CLI is not currently
available, potentially add an 'Establish Connection' button to the tab with the
capability to prompt for a username and password if required and make use of the
discovered address.
> -Add an MBean that can handle management ops, the CLI integration can use that
MBean regardless of the connection method and would not require the establishment of
additional connections.
>
> So, any comments/suggestions?
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:06 p.m.
AIUI Darran's objection, this isn't particularly related to domain mode.
It's that our jconsole plugin shouldn't be opening remoting connections
to an arbitrary URL when the user has configured a direct connection.
I agree with that and am fine with removing this feature from WF 8 and
just putting explanatory text in the tab.
What if they have 2 servers on the machine, one 9990 and the other on
9991 and they direct connect to the 9991 process?
On 8/5/13 8:34 AM, Jaikiran Pai wrote:
It's this PR https://github.com/wildfly/wildfly/pull/4662 (which
we
closed pending discussion).
-Jaikiran
On Monday 05 August 2013 06:46 PM, ssilvert(a)redhat.com wrote:
> I can't find the PR you are referring to and I'm not sure I fully
> understand what the problem is.
>
> However, I can tell you that the original goal was to make this work
> just like 'jboss-cli -c' where if you don't specify anything it will try
> to connect using our best guess of localhost:9990. If you can make that
> smarter I don't see how it breaks backward compatibility. It sounds to
> me like a good enhancement.
>
> But Darran's objection may have something to do with what happens in a
> domain environment. It's possible to connect jconsole to a server
> instance that is not the domain controller. In that case you can't
> (shouldn't?) connect CLI to it. So automatic discovery might discover
> something that is bogus from a CLI point of view.
>
> Stan
>
> On 8/5/2013 4:52 AM, Bartosz Baranowski wrote:
>> Hey Guys.
>>
>> I missed last comment on related PR, hence I did not start this thread.
>>
>> Currently JConsole plugin does something like:
>>
>> if(as7Remoting){
>> //use
>> } else {
>> //discard connection
>> // try to connect on hardcoded values locahost:9990
>> }
>>
>>
https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jbos...
>>
>> Ive propesed a change to use existing connection to query for proper IP/port pair
of management interface and than attempt to use cmdContext.connect. However it has been
deemed as unfit fix - even though it just addapts IP/port rather than make plugin always
use localhost:9990.
>>
>>
>> Darran commented on this at some point:
>>
>> "However as I have said elsehwere I think this is attempting to fix a
'feature' that should not exist in it's current form"
>> Trick is that this "feature" is there, its faulty, but if its removed,
it breaks backward compatibility.
>>
>> Also:
>>
>> Where jconsole is connected to the process locally I suggest two alternatives: -
>> - Add the CLI tab but with a clear message stating why the CLI is not
currently available, potentially add an 'Establish Connection' button to the tab
with the capability to prompt for a username and password if required and make use of the
discovered address.
>> -Add an MBean that can handle management ops, the CLI integration can use that
MBean regardless of the connection method and would not require the establishment of
additional connections.
>>
>> So, any comments/suggestions?
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
4:09 p.m.
On 8/5/2013 9:34 AM, Jaikiran Pai wrote:
It's this PR https://github.com/wildfly/wildfly/pull/4662 (which
we
closed pending discussion).
I see now. Perhaps Darran can elaborate on his
objections. Security
concerns maybe?
BTW, I think you meant to remove line 117 of your commit:
if(true)throw new IOException();
-Jaikiran
On Monday 05 August 2013 06:46 PM, ssilvert(a)redhat.com wrote:
> I can't find the PR you are referring to and I'm not sure I fully
> understand what the problem is.
>
> However, I can tell you that the original goal was to make this work
> just like 'jboss-cli -c' where if you don't specify anything it will try
> to connect using our best guess of localhost:9990. If you can make that
> smarter I don't see how it breaks backward compatibility. It sounds to
> me like a good enhancement.
>
> But Darran's objection may have something to do with what happens in a
> domain environment. It's possible to connect jconsole to a server
> instance that is not the domain controller. In that case you can't
> (shouldn't?) connect CLI to it. So automatic discovery might discover
> something that is bogus from a CLI point of view.
>
> Stan
>
> On 8/5/2013 4:52 AM, Bartosz Baranowski wrote:
>> Hey Guys.
>>
>> I missed last comment on related PR, hence I did not start this thread.
>>
>> Currently JConsole plugin does something like:
>>
>> if(as7Remoting){
>> //use
>> } else {
>> //discard connection
>> // try to connect on hardcoded values locahost:9990
>> }
>>
>>
https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jbos...
>>
>>
>> Ive propesed a change to use existing connection to query for proper
>> IP/port pair of management interface and than attempt to use
>> cmdContext.connect. However it has been deemed as unfit fix - even
>> though it just addapts IP/port rather than make plugin always use
>> localhost:9990.
>>
>>
>> Darran commented on this at some point:
>>
>> "However as I have said elsehwere I think this is attempting to fix
>> a 'feature' that should not exist in it's current form"
>> Trick is that this "feature" is there, its faulty, but if its
>> removed, it breaks backward compatibility.
>>
>> Also:
>>
>> Where jconsole is connected to the process locally I suggest two
>> alternatives: -
>> - Add the CLI tab but with a clear message stating why the CLI is
>> not currently available, potentially add an 'Establish Connection'
>> button to the tab with the capability to prompt for a username and
>> password if required and make use of the discovered address.
>> -Add an MBean that can handle management ops, the CLI integration
>> can use that MBean regardless of the connection method and would not
>> require the establishment of additional connections.
>>
>> So, any comments/suggestions?
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:20 p.m.
On 8/5/2013 10:06 AM, Brian Stansberry wrote:
AIUI Darran's objection, this isn't particularly related to
domain mode.
It's that our jconsole plugin shouldn't be opening remoting connections
to an arbitrary URL when the user has configured a direct connection.
The intention
here is that the CLI plugin should work when the user has
NOT configured a direct remoting connection. You can launch jconsole,
click on the local server process, and CLI connects automatically. It's
much easier than typing the hard-to-remember remoting URL. It's just
two clicks and you are done.
I agree with that and am fine with removing this feature from WF 8 and
just putting explanatory text in the tab.
What if they have 2 servers on the machine, one 9990 and the other on
9991 and they direct connect to the 9991 process?
Don't we have the same kind
of problem with 'jboss-cli -c' ? It does
the right thing 99.9% of the time. It's just a convenience for the
localhost developer.
On 8/5/13 8:34 AM, Jaikiran Pai wrote:
> It's this PR https://github.com/wildfly/wildfly/pull/4662 (which we
> closed pending discussion).
>
> -Jaikiran
> On Monday 05 August 2013 06:46 PM, ssilvert(a)redhat.com wrote:
>> I can't find the PR you are referring to and I'm not sure I fully
>> understand what the problem is.
>>
>> However, I can tell you that the original goal was to make this work
>> just like 'jboss-cli -c' where if you don't specify anything it will
try
>> to connect using our best guess of localhost:9990. If you can make that
>> smarter I don't see how it breaks backward compatibility. It sounds to
>> me like a good enhancement.
>>
>> But Darran's objection may have something to do with what happens in a
>> domain environment. It's possible to connect jconsole to a server
>> instance that is not the domain controller. In that case you can't
>> (shouldn't?) connect CLI to it. So automatic discovery might discover
>> something that is bogus from a CLI point of view.
>>
>> Stan
>>
>> On 8/5/2013 4:52 AM, Bartosz Baranowski wrote:
>>> Hey Guys.
>>>
>>> I missed last comment on related PR, hence I did not start this thread.
>>>
>>> Currently JConsole plugin does something like:
>>>
>>> if(as7Remoting){
>>> //use
>>> } else {
>>> //discard connection
>>> // try to connect on hardcoded values locahost:9990
>>> }
>>>
>>>
https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jbos...
>>>
>>> Ive propesed a change to use existing connection to query for proper IP/port
pair of management interface and than attempt to use cmdContext.connect. However it has
been deemed as unfit fix - even though it just addapts IP/port rather than make plugin
always use localhost:9990.
>>>
>>>
>>> Darran commented on this at some point:
>>>
>>> "However as I have said elsehwere I think this is attempting to fix a
'feature' that should not exist in it's current form"
>>> Trick is that this "feature" is there, its faulty, but if its
removed, it breaks backward compatibility.
>>>
>>> Also:
>>>
>>> Where jconsole is connected to the process locally I suggest two
alternatives: -
>>> - Add the CLI tab but with a clear message stating why the CLI is not
currently available, potentially add an 'Establish Connection' button to the tab
with the capability to prompt for a username and password if required and make use of the
discovered address.
>>> -Add an MBean that can handle management ops, the CLI integration can use
that MBean regardless of the connection method and would not require the establishment of
additional connections.
>>>
>>> So, any comments/suggestions?
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
4:42 p.m.
On 05/08/13 15:20, ssilvert(a)redhat.com wrote:
On 8/5/2013 10:06 AM, Brian Stansberry wrote:
> AIUI Darran's objection, this isn't particularly related to domain mode.
> It's that our jconsole plugin shouldn't be opening remoting connections
> to an arbitrary URL when the user has configured a direct connection.
The intention here is that the CLI plugin should work when the user has
NOT configured a direct remoting connection. You can launch jconsole,
click on the local server process, and CLI connects automatically. It's
much easier than typing the hard-to-remember remoting URL. It's just
two clicks and you are done.
>
> I agree with that and am fine with removing this feature from WF 8 and
> just putting explanatory text in the tab.
>
> What if they have 2 servers on the machine, one 9990 and the other on
> 9991 and they direct connect to the 9991 process?
Don't we have the same kind of problem with 'jboss-cli -c' ? It does
the right thing 99.9% of the time. It's just a convenience for the
localhost developer.
No the CLI has configuration to specify which host to connect to.
Secondly the CLI will enter into an interactive prompt with the end user
if authentication is required.
>
> On 8/5/13 8:34 AM, Jaikiran Pai wrote:
>> It's this PR https://github.com/wildfly/wildfly/pull/4662 (which we
>> closed pending discussion).
>>
>> -Jaikiran
>> On Monday 05 August 2013 06:46 PM, ssilvert(a)redhat.com wrote:
>>> I can't find the PR you are referring to and I'm not sure I fully
>>> understand what the problem is.
>>>
>>> However, I can tell you that the original goal was to make this work
>>> just like 'jboss-cli -c' where if you don't specify anything it
will try
>>> to connect using our best guess of localhost:9990. If you can make that
>>> smarter I don't see how it breaks backward compatibility. It sounds to
>>> me like a good enhancement.
>>>
>>> But Darran's objection may have something to do with what happens in a
>>> domain environment. It's possible to connect jconsole to a server
>>> instance that is not the domain controller. In that case you can't
>>> (shouldn't?) connect CLI to it. So automatic discovery might discover
>>> something that is bogus from a CLI point of view.
>>>
>>> Stan
>>>
>>> On 8/5/2013 4:52 AM, Bartosz Baranowski wrote:
>>>> Hey Guys.
>>>>
>>>> I missed last comment on related PR, hence I did not start this thread.
>>>>
>>>> Currently JConsole plugin does something like:
>>>>
>>>> if(as7Remoting){
>>>> //use
>>>> } else {
>>>> //discard connection
>>>> // try to connect on hardcoded values locahost:9990
>>>> }
>>>>
>>>>
https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jbos...
>>>>
>>>> Ive propesed a change to use existing connection to query for proper
IP/port pair of management interface and than attempt to use cmdContext.connect. However
it has been deemed as unfit fix - even though it just addapts IP/port rather than make
plugin always use localhost:9990.
>>>>
>>>>
>>>> Darran commented on this at some point:
>>>>
>>>> "However as I have said elsehwere I think this is attempting to fix
a 'feature' that should not exist in it's current form"
>>>> Trick is that this "feature" is there, its faulty, but if its
removed, it breaks backward compatibility.
>>>>
>>>> Also:
>>>>
>>>> Where jconsole is connected to the process locally I suggest two
alternatives: -
>>>> - Add the CLI tab but with a clear message stating why the CLI is not
currently available, potentially add an 'Establish Connection' button to the tab
with the capability to prompt for a username and password if required and make use of the
discovered address.
>>>> -Add an MBean that can handle management ops, the CLI integration can
use that MBean regardless of the connection method and would not require the establishment
of additional connections.
>>>>
>>>> So, any comments/suggestions?
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:48 p.m.
On 05/08/13 15:09, ssilvert(a)redhat.com wrote:
On 8/5/2013 9:34 AM, Jaikiran Pai wrote:
> It's this PR https://github.com/wildfly/wildfly/pull/4662 (which we
> closed pending discussion).
I see now. Perhaps Darran can elaborate on his objections. Security
concerns maybe?
My concern is that we still do not have a complete solution, we have
taken the default config - made one change and the feature is broken, we
now have a proposed fix to overcome that change but we are still only
one config change away from breaking it again should the local auth
mechanism be removed.
Hence the two suggestions I made for a more complete solution: -
1 - Proxy through an MBean.
2 - Add a 'Connect' button to the tab that allows interaction with the
user if a username and password is needed.
BTW, I think you meant to remove line 117 of your commit:
if(true)throw new IOException();
>
> -Jaikiran
> On Monday 05 August 2013 06:46 PM, ssilvert(a)redhat.com wrote:
>> I can't find the PR you are referring to and I'm not sure I fully
>> understand what the problem is.
>>
>> However, I can tell you that the original goal was to make this work
>> just like 'jboss-cli -c' where if you don't specify anything it will
try
>> to connect using our best guess of localhost:9990. If you can make that
>> smarter I don't see how it breaks backward compatibility. It sounds to
>> me like a good enhancement.
>>
>> But Darran's objection may have something to do with what happens in a
>> domain environment. It's possible to connect jconsole to a server
>> instance that is not the domain controller. In that case you can't
>> (shouldn't?) connect CLI to it. So automatic discovery might discover
>> something that is bogus from a CLI point of view.
>>
>> Stan
>>
>> On 8/5/2013 4:52 AM, Bartosz Baranowski wrote:
>>> Hey Guys.
>>>
>>> I missed last comment on related PR, hence I did not start this thread.
>>>
>>> Currently JConsole plugin does something like:
>>>
>>> if(as7Remoting){
>>> //use
>>> } else {
>>> //discard connection
>>> // try to connect on hardcoded values locahost:9990
>>> }
>>>
>>>
https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jbos...
>>>
>>>
>>> Ive propesed a change to use existing connection to query for proper
>>> IP/port pair of management interface and than attempt to use
>>> cmdContext.connect. However it has been deemed as unfit fix - even
>>> though it just addapts IP/port rather than make plugin always use
>>> localhost:9990.
>>>
>>>
>>> Darran commented on this at some point:
>>>
>>> "However as I have said elsehwere I think this is attempting to fix
>>> a 'feature' that should not exist in it's current form"
>>> Trick is that this "feature" is there, its faulty, but if its
>>> removed, it breaks backward compatibility.
>>>
>>> Also:
>>>
>>> Where jconsole is connected to the process locally I suggest two
>>> alternatives: -
>>> - Add the CLI tab but with a clear message stating why the CLI is
>>> not currently available, potentially add an 'Establish Connection'
>>> button to the tab with the capability to prompt for a username and
>>> password if required and make use of the discovered address.
>>> -Add an MBean that can handle management ops, the CLI integration
>>> can use that MBean regardless of the connection method and would not
>>> require the establishment of additional connections.
>>>
>>> So, any comments/suggestions?
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
5:01 p.m.
On 8/5/13 9:20 AM, ssilvert(a)redhat.com wrote:
On 8/5/2013 10:06 AM, Brian Stansberry wrote:
> AIUI Darran's objection, this isn't particularly related to domain mode.
> It's that our jconsole plugin shouldn't be opening remoting connections
> to an arbitrary URL when the user has configured a direct connection.
The intention here is that the CLI plugin should work when the user has
NOT configured a direct remoting connection. You can launch jconsole,
click on the local server process, and CLI connects automatically. It's
much easier than typing the hard-to-remember remoting URL. It's just
two clicks and you are done.
>
> I agree with that and am fine with removing this feature from WF 8 and
> just putting explanatory text in the tab.
>
> What if they have 2 servers on the machine, one 9990 and the other on
> 9991 and they direct connect to the 9991 process?
Don't we have the same kind of problem with 'jboss-cli -c' ? It does
the right thing 99.9% of the time. It's just a convenience for the
localhost developer.
The jboss-cli command is a WildFly command, unlike jconsole. A user can
read our documentation and understand what the impact of command line
options will be, and if they don't and get unexpected behavior I don't
think they'll be greatly surprised. The jconsole connection dialogue is
part of jconsole, not part of our plugin. A user cannot read standard
jconsole documentation and understand that with this particular mbean
server the direct connection option will result in a remoting connection
being opened to an arbitrary URL.
>
> On 8/5/13 8:34 AM, Jaikiran Pai wrote:
>> It's this PR https://github.com/wildfly/wildfly/pull/4662 (which we
>> closed pending discussion).
>>
>> -Jaikiran
>> On Monday 05 August 2013 06:46 PM, ssilvert(a)redhat.com wrote:
>>> I can't find the PR you are referring to and I'm not sure I fully
>>> understand what the problem is.
>>>
>>> However, I can tell you that the original goal was to make this work
>>> just like 'jboss-cli -c' where if you don't specify anything it
will try
>>> to connect using our best guess of localhost:9990. If you can make that
>>> smarter I don't see how it breaks backward compatibility. It sounds to
>>> me like a good enhancement.
>>>
>>> But Darran's objection may have something to do with what happens in a
>>> domain environment. It's possible to connect jconsole to a server
>>> instance that is not the domain controller. In that case you can't
>>> (shouldn't?) connect CLI to it. So automatic discovery might discover
>>> something that is bogus from a CLI point of view.
>>>
>>> Stan
>>>
>>> On 8/5/2013 4:52 AM, Bartosz Baranowski wrote:
>>>> Hey Guys.
>>>>
>>>> I missed last comment on related PR, hence I did not start this thread.
>>>>
>>>> Currently JConsole plugin does something like:
>>>>
>>>> if(as7Remoting){
>>>> //use
>>>> } else {
>>>> //discard connection
>>>> // try to connect on hardcoded values locahost:9990
>>>> }
>>>>
>>>>
https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jbos...
>>>>
>>>> Ive propesed a change to use existing connection to query for proper
IP/port pair of management interface and than attempt to use cmdContext.connect. However
it has been deemed as unfit fix - even though it just addapts IP/port rather than make
plugin always use localhost:9990.
>>>>
>>>>
>>>> Darran commented on this at some point:
>>>>
>>>> "However as I have said elsehwere I think this is attempting to fix
a 'feature' that should not exist in it's current form"
>>>> Trick is that this "feature" is there, its faulty, but if its
removed, it breaks backward compatibility.
>>>>
>>>> Also:
>>>>
>>>> Where jconsole is connected to the process locally I suggest two
alternatives: -
>>>> - Add the CLI tab but with a clear message stating why the CLI is not
currently available, potentially add an 'Establish Connection' button to the tab
with the capability to prompt for a username and password if required and make use of the
discovered address.
>>>> -Add an MBean that can handle management ops, the CLI integration can
use that MBean regardless of the connection method and would not require the establishment
of additional connections.
>>>>
>>>> So, any comments/suggestions?
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
5:47 p.m.
On 8/5/2013 10:48 AM, Darran Lofthouse wrote:
On 05/08/13 15:09, ssilvert(a)redhat.com wrote:
> On 8/5/2013 9:34 AM, Jaikiran Pai wrote:
>> It's this PR https://github.com/wildfly/wildfly/pull/4662 (which we
>> closed pending discussion).
> I see now. Perhaps Darran can elaborate on his objections. Security
> concerns maybe?
My concern is that we still do not have a complete solution, we have
taken the default config - made one change and the feature is broken,
we now have a proposed fix to overcome that change but we are still
only one config change away from breaking it again should the local
auth mechanism be removed.
Hence the two suggestions I made for a more complete solution: -
1 - Proxy through an MBean.
2 - Add a 'Connect' button to the tab that allows interaction with
the user if a username and password is needed.
As long as it is as easy to use as
'jboss-cli -c' then I'm all for it.
Bartosz, do you want to implement it?
> BTW, I think you meant to remove line 117 of your commit:
> if(true)throw new IOException();
>
>>
>> -Jaikiran
>> On Monday 05 August 2013 06:46 PM, ssilvert(a)redhat.com wrote:
>>> I can't find the PR you are referring to and I'm not sure I fully
>>> understand what the problem is.
>>>
>>> However, I can tell you that the original goal was to make this work
>>> just like 'jboss-cli -c' where if you don't specify anything it
>>> will try
>>> to connect using our best guess of localhost:9990. If you can make
>>> that
>>> smarter I don't see how it breaks backward compatibility. It
>>> sounds to
>>> me like a good enhancement.
>>>
>>> But Darran's objection may have something to do with what happens in a
>>> domain environment. It's possible to connect jconsole to a server
>>> instance that is not the domain controller. In that case you can't
>>> (shouldn't?) connect CLI to it. So automatic discovery might discover
>>> something that is bogus from a CLI point of view.
>>>
>>> Stan
>>>
>>> On 8/5/2013 4:52 AM, Bartosz Baranowski wrote:
>>>> Hey Guys.
>>>>
>>>> I missed last comment on related PR, hence I did not start this
>>>> thread.
>>>>
>>>> Currently JConsole plugin does something like:
>>>>
>>>> if(as7Remoting){
>>>> //use
>>>> } else {
>>>> //discard connection
>>>> // try to connect on hardcoded values locahost:9990
>>>> }
>>>>
>>>>
https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jbos...
>>>>
>>>>
>>>>
>>>> Ive propesed a change to use existing connection to query for proper
>>>> IP/port pair of management interface and than attempt to use
>>>> cmdContext.connect. However it has been deemed as unfit fix - even
>>>> though it just addapts IP/port rather than make plugin always use
>>>> localhost:9990.
>>>>
>>>>
>>>> Darran commented on this at some point:
>>>>
>>>> "However as I have said elsehwere I think this is attempting to fix
>>>> a 'feature' that should not exist in it's current form"
>>>> Trick is that this "feature" is there, its faulty, but if its
>>>> removed, it breaks backward compatibility.
>>>>
>>>> Also:
>>>>
>>>> Where jconsole is connected to the process locally I suggest two
>>>> alternatives: -
>>>> - Add the CLI tab but with a clear message stating why the CLI is
>>>> not currently available, potentially add an 'Establish
Connection'
>>>> button to the tab with the capability to prompt for a username and
>>>> password if required and make use of the discovered address.
>>>> -Add an MBean that can handle management ops, the CLI integration
>>>> can use that MBean regardless of the connection method and would not
>>>> require the establishment of additional connections.
>>>>
>>>> So, any comments/suggestions?
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
5:58 p.m.
On 8/5/2013 11:01 AM, Brian Stansberry wrote:
On 8/5/13 9:20 AM, ssilvert(a)redhat.com wrote:
> On 8/5/2013 10:06 AM, Brian Stansberry wrote:
>> AIUI Darran's objection, this isn't particularly related to domain mode.
>> It's that our jconsole plugin shouldn't be opening remoting connections
>> to an arbitrary URL when the user has configured a direct connection.
> The intention here is that the CLI plugin should work when the user has
> NOT configured a direct remoting connection. You can launch jconsole,
> click on the local server process, and CLI connects automatically. It's
> much easier than typing the hard-to-remember remoting URL. It's just
> two clicks and you are done.
>> I agree with that and am fine with removing this feature from WF 8 and
>> just putting explanatory text in the tab.
>>
>> What if they have 2 servers on the machine, one 9990 and the other on
>> 9991 and they direct connect to the 9991 process?
> Don't we have the same kind of problem with 'jboss-cli -c' ? It does
> the right thing 99.9% of the time. It's just a convenience for the
> localhost developer.
>
The jboss-cli command is a WildFly command, unlike jconsole. A user can
read our documentation and understand what the impact of command line
options will be, and if they don't and get unexpected behavior I don't
think they'll be greatly surprised. The jconsole connection dialogue is
part of jconsole, not part of our plugin. A user cannot read standard
jconsole documentation and understand that with this particular mbean
server the direct connection option will result in a remoting connection
being opened to an arbitrary URL.
In this case, jconsole actually IS a WildFly
command. This won't work
at all with the standard jconsole. You have to use our
jconsole.sh/bat. So it should be covered by our docs.
Both 'jboss-cli -c' and jconsole cli plugin could give you an unexpected
connection if you aren't careful. But this is rare and it's a tradeoff
we've been willing to live with. I think Darran's suggestions get us
closer to having something that gives the user the info they need while
maintaining the ease of use.
>> On 8/5/13 8:34 AM, Jaikiran Pai wrote:
>>> It's this PR https://github.com/wildfly/wildfly/pull/4662 (which we
>>> closed pending discussion).
>>>
>>> -Jaikiran
>>> On Monday 05 August 2013 06:46 PM, ssilvert(a)redhat.com wrote:
>>>> I can't find the PR you are referring to and I'm not sure I
fully
>>>> understand what the problem is.
>>>>
>>>> However, I can tell you that the original goal was to make this work
>>>> just like 'jboss-cli -c' where if you don't specify anything
it will try
>>>> to connect using our best guess of localhost:9990. If you can make that
>>>> smarter I don't see how it breaks backward compatibility. It sounds
to
>>>> me like a good enhancement.
>>>>
>>>> But Darran's objection may have something to do with what happens in
a
>>>> domain environment. It's possible to connect jconsole to a server
>>>> instance that is not the domain controller. In that case you can't
>>>> (shouldn't?) connect CLI to it. So automatic discovery might
discover
>>>> something that is bogus from a CLI point of view.
>>>>
>>>> Stan
>>>>
>>>> On 8/5/2013 4:52 AM, Bartosz Baranowski wrote:
>>>>> Hey Guys.
>>>>>
>>>>> I missed last comment on related PR, hence I did not start this
thread.
>>>>>
>>>>> Currently JConsole plugin does something like:
>>>>>
>>>>> if(as7Remoting){
>>>>> //use
>>>>> } else {
>>>>> //discard connection
>>>>> // try to connect on hardcoded values locahost:9990
>>>>> }
>>>>>
>>>>>
https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jbos...
>>>>>
>>>>> Ive propesed a change to use existing connection to query for proper
IP/port pair of management interface and than attempt to use cmdContext.connect. However
it has been deemed as unfit fix - even though it just addapts IP/port rather than make
plugin always use localhost:9990.
>>>>>
>>>>>
>>>>> Darran commented on this at some point:
>>>>>
>>>>> "However as I have said elsehwere I think this is attempting to
fix a 'feature' that should not exist in it's current form"
>>>>> Trick is that this "feature" is there, its faulty, but if
its removed, it breaks backward compatibility.
>>>>>
>>>>> Also:
>>>>>
>>>>> Where jconsole is connected to the process locally I suggest two
alternatives: -
>>>>> - Add the CLI tab but with a clear message stating why the CLI is
not currently available, potentially add an 'Establish Connection' button to the
tab with the capability to prompt for a username and password if required and make use of
the discovered address.
>>>>> -Add an MBean that can handle management ops, the CLI integration
can use that MBean regardless of the connection method and would not require the
establishment of additional connections.
>>>>>
>>>>> So, any comments/suggestions?
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
7:14 p.m.
On 8/5/13 10:58 AM, ssilvert(a)redhat.com wrote:
On 8/5/2013 11:01 AM, Brian Stansberry wrote:
> On 8/5/13 9:20 AM, ssilvert(a)redhat.com wrote:
>> On 8/5/2013 10:06 AM, Brian Stansberry wrote:
>>> AIUI Darran's objection, this isn't particularly related to domain
mode.
>>> It's that our jconsole plugin shouldn't be opening remoting
connections
>>> to an arbitrary URL when the user has configured a direct connection.
>> The intention here is that the CLI plugin should work when the user has
>> NOT configured a direct remoting connection. You can launch jconsole,
>> click on the local server process, and CLI connects automatically. It's
>> much easier than typing the hard-to-remember remoting URL. It's just
>> two clicks and you are done.
>>> I agree with that and am fine with removing this feature from WF 8 and
>>> just putting explanatory text in the tab.
>>>
>>> What if they have 2 servers on the machine, one 9990 and the other on
>>> 9991 and they direct connect to the 9991 process?
>> Don't we have the same kind of problem with 'jboss-cli -c' ? It
does
>> the right thing 99.9% of the time. It's just a convenience for the
>> localhost developer.
>>
> The jboss-cli command is a WildFly command, unlike jconsole. A user can
> read our documentation and understand what the impact of command line
> options will be, and if they don't and get unexpected behavior I don't
> think they'll be greatly surprised. The jconsole connection dialogue is
> part of jconsole, not part of our plugin. A user cannot read standard
> jconsole documentation and understand that with this particular mbean
> server the direct connection option will result in a remoting connection
> being opened to an arbitrary URL.
In this case, jconsole actually IS a WildFly command. This won't work
at all with the standard jconsole. You have to use our
jconsole.sh/bat. So it should be covered by our docs.
I'm not buying this argument, because the jconsole connect dialogue is
the relevant part, not the launch script. But, no matter, since...
Both 'jboss-cli -c' and jconsole cli plugin could give you an
unexpected
connection if you aren't careful. But this is rare and it's a tradeoff
we've been willing to live with. I think Darran's suggestions get us
closer to having something that gives the user the info they need while
maintaining the ease of use.
Yes, those sound much better.
>
>>> On 8/5/13 8:34 AM, Jaikiran Pai wrote:
>>>> It's this PR https://github.com/wildfly/wildfly/pull/4662 (which we
>>>> closed pending discussion).
>>>>
>>>> -Jaikiran
>>>> On Monday 05 August 2013 06:46 PM, ssilvert(a)redhat.com wrote:
>>>>> I can't find the PR you are referring to and I'm not sure I
fully
>>>>> understand what the problem is.
>>>>>
>>>>> However, I can tell you that the original goal was to make this work
>>>>> just like 'jboss-cli -c' where if you don't specify
anything it will try
>>>>> to connect using our best guess of localhost:9990. If you can make
that
>>>>> smarter I don't see how it breaks backward compatibility. It
sounds to
>>>>> me like a good enhancement.
>>>>>
>>>>> But Darran's objection may have something to do with what happens
in a
>>>>> domain environment. It's possible to connect jconsole to a
server
>>>>> instance that is not the domain controller. In that case you
can't
>>>>> (shouldn't?) connect CLI to it. So automatic discovery might
discover
>>>>> something that is bogus from a CLI point of view.
>>>>>
>>>>> Stan
>>>>>
>>>>> On 8/5/2013 4:52 AM, Bartosz Baranowski wrote:
>>>>>> Hey Guys.
>>>>>>
>>>>>> I missed last comment on related PR, hence I did not start this
thread.
>>>>>>
>>>>>> Currently JConsole plugin does something like:
>>>>>>
>>>>>> if(as7Remoting){
>>>>>> //use
>>>>>> } else {
>>>>>> //discard connection
>>>>>> // try to connect on hardcoded values locahost:9990
>>>>>> }
>>>>>>
>>>>>>
https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jbos...
>>>>>>
>>>>>> Ive propesed a change to use existing connection to query for
proper IP/port pair of management interface and than attempt to use cmdContext.connect.
However it has been deemed as unfit fix - even though it just addapts IP/port rather than
make plugin always use localhost:9990.
>>>>>>
>>>>>>
>>>>>> Darran commented on this at some point:
>>>>>>
>>>>>> "However as I have said elsehwere I think this is attempting
to fix a 'feature' that should not exist in it's current form"
>>>>>> Trick is that this "feature" is there, its faulty, but
if its removed, it breaks backward compatibility.
>>>>>>
>>>>>> Also:
>>>>>>
>>>>>> Where jconsole is connected to the process locally I suggest two
alternatives: -
>>>>>> - Add the CLI tab but with a clear message stating why the
CLI is not currently available, potentially add an 'Establish Connection' button
to the tab with the capability to prompt for a username and password if required and make
use of the discovered address.
>>>>>> -Add an MBean that can handle management ops, the CLI
integration can use that MBean regardless of the connection method and would not require
the establishment of additional connections.
>>>>>>
>>>>>> So, any comments/suggestions?
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
2:22 p.m.
----- Original Message -----
From: ssilvert(a)redhat.com
To: jpai(a)redhat.com
Cc: wildfly-dev(a)lists.jboss.org
Sent: Monday, August 5, 2013 4:09:02 PM
Subject: Re: [wildfly-dev] JConsole plugin - fallback and query for management address
On 8/5/2013 9:34 AM, Jaikiran Pai wrote:
> It's this PR https://github.com/wildfly/wildfly/pull/4662 (which we
> closed pending discussion).
I see now. Perhaps Darran can elaborate on his objections. Security
concerns maybe?
BTW, I think you meant to remove line 117 of your commit:
if(true)throw new IOException();
Indeed. Missed this when I was doing a house
keeping.
>
> -Jaikiran
> On Monday 05 August 2013 06:46 PM, ssilvert(a)redhat.com wrote:
>> I can't find the PR you are referring to and I'm not sure I fully
>> understand what the problem is.
>>
>> However, I can tell you that the original goal was to make this work
>> just like 'jboss-cli -c' where if you don't specify anything it will
try
>> to connect using our best guess of localhost:9990. If you can make that
>> smarter I don't see how it breaks backward compatibility. It sounds to
>> me like a good enhancement.
>>
>> But Darran's objection may have something to do with what happens in a
>> domain environment. It's possible to connect jconsole to a server
>> instance that is not the domain controller. In that case you can't
>> (shouldn't?) connect CLI to it. So automatic discovery might discover
>> something that is bogus from a CLI point of view.
>>
>> Stan
>>
>> On 8/5/2013 4:52 AM, Bartosz Baranowski wrote:
>>> Hey Guys.
>>>
>>> I missed last comment on related PR, hence I did not start this thread.
>>>
>>> Currently JConsole plugin does something like:
>>>
>>> if(as7Remoting){
>>> //use
>>> } else {
>>> //discard connection
>>> // try to connect on hardcoded values locahost:9990
>>> }
>>>
>>>
https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jbos...
>>>
>>>
>>> Ive propesed a change to use existing connection to query for proper
>>> IP/port pair of management interface and than attempt to use
>>> cmdContext.connect. However it has been deemed as unfit fix - even
>>> though it just addapts IP/port rather than make plugin always use
>>> localhost:9990.
>>>
>>>
>>> Darran commented on this at some point:
>>>
>>> "However as I have said elsehwere I think this is attempting to fix
>>> a 'feature' that should not exist in it's current form"
>>> Trick is that this "feature" is there, its faulty, but if its
>>> removed, it breaks backward compatibility.
>>>
>>> Also:
>>>
>>> Where jconsole is connected to the process locally I suggest two
>>> alternatives: -
>>> - Add the CLI tab but with a clear message stating why the CLI is
>>> not currently available, potentially add an 'Establish Connection'
>>> button to the tab with the capability to prompt for a username and
>>> password if required and make use of the discovered address.
>>> -Add an MBean that can handle management ops, the CLI integration
>>> can use that MBean regardless of the connection method and would not
>>> require the establishment of additional connections.
>>>
>>> So, any comments/suggestions?
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:24 p.m.
----- Original Message -----
From: ssilvert(a)redhat.com
To: "Darran Lofthouse" <darran.lofthouse(a)jboss.com>
Cc: wildfly-dev(a)lists.jboss.org
Sent: Monday, August 5, 2013 5:47:11 PM
Subject: Re: [wildfly-dev] JConsole plugin - fallback and query for management address
On 8/5/2013 10:48 AM, Darran Lofthouse wrote:
> On 05/08/13 15:09, ssilvert(a)redhat.com wrote:
>> On 8/5/2013 9:34 AM, Jaikiran Pai wrote:
>>> It's this PR https://github.com/wildfly/wildfly/pull/4662 (which we
>>> closed pending discussion).
>> I see now. Perhaps Darran can elaborate on his objections. Security
>> concerns maybe?
>
> My concern is that we still do not have a complete solution, we have
> taken the default config - made one change and the feature is broken,
> we now have a proposed fix to overcome that change but we are still
> only one config change away from breaking it again should the local
> auth mechanism be removed.
>
> Hence the two suggestions I made for a more complete solution: -
> 1 - Proxy through an MBean.
> 2 - Add a 'Connect' button to the tab that allows interaction with
> the user if a username and password is needed.
As long as it is as easy to use as 'jboss-cli -c' then I'm all for it.
Bartosz, do you want to implement it?
Yeah. I just need a course to follow. Hence
this thread.
>
>> BTW, I think you meant to remove line 117 of your commit:
>> if(true)throw new IOException();
>>
>>>
>>> -Jaikiran
>>> On Monday 05 August 2013 06:46 PM, ssilvert(a)redhat.com wrote:
>>>> I can't find the PR you are referring to and I'm not sure I
fully
>>>> understand what the problem is.
>>>>
>>>> However, I can tell you that the original goal was to make this work
>>>> just like 'jboss-cli -c' where if you don't specify anything
it
>>>> will try
>>>> to connect using our best guess of localhost:9990. If you can make
>>>> that
>>>> smarter I don't see how it breaks backward compatibility. It
>>>> sounds to
>>>> me like a good enhancement.
>>>>
>>>> But Darran's objection may have something to do with what happens in
a
>>>> domain environment. It's possible to connect jconsole to a server
>>>> instance that is not the domain controller. In that case you can't
>>>> (shouldn't?) connect CLI to it. So automatic discovery might
discover
>>>> something that is bogus from a CLI point of view.
>>>>
>>>> Stan
>>>>
>>>> On 8/5/2013 4:52 AM, Bartosz Baranowski wrote:
>>>>> Hey Guys.
>>>>>
>>>>> I missed last comment on related PR, hence I did not start this
>>>>> thread.
>>>>>
>>>>> Currently JConsole plugin does something like:
>>>>>
>>>>> if(as7Remoting){
>>>>> //use
>>>>> } else {
>>>>> //discard connection
>>>>> // try to connect on hardcoded values locahost:9990
>>>>> }
>>>>>
>>>>>
https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jbos...
>>>>>
>>>>>
>>>>>
>>>>> Ive propesed a change to use existing connection to query for
proper
>>>>> IP/port pair of management interface and than attempt to use
>>>>> cmdContext.connect. However it has been deemed as unfit fix - even
>>>>> though it just addapts IP/port rather than make plugin always use
>>>>> localhost:9990.
>>>>>
>>>>>
>>>>> Darran commented on this at some point:
>>>>>
>>>>> "However as I have said elsehwere I think this is attempting to
fix
>>>>> a 'feature' that should not exist in it's current
form"
>>>>> Trick is that this "feature" is there, its faulty, but if
its
>>>>> removed, it breaks backward compatibility.
>>>>>
>>>>> Also:
>>>>>
>>>>> Where jconsole is connected to the process locally I suggest two
>>>>> alternatives: -
>>>>> - Add the CLI tab but with a clear message stating why the CLI
is
>>>>> not currently available, potentially add an 'Establish
Connection'
>>>>> button to the tab with the capability to prompt for a username and
>>>>> password if required and make use of the discovered address.
>>>>> -Add an MBean that can handle management ops, the CLI
integration
>>>>> can use that MBean regardless of the connection method and would
not
>>>>> require the establishment of additional connections.
>>>>>
>>>>> So, any comments/suggestions?
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:27 p.m.
----- Original Message -----
From: "Brian Stansberry"
<brian.stansberry(a)redhat.com>
To: wildfly-dev(a)lists.jboss.org
Sent: Monday, August 5, 2013 7:14:51 PM
Subject: Re: [wildfly-dev] JConsole plugin - fallback and query for management address
On 8/5/13 10:58 AM, ssilvert(a)redhat.com wrote:
> On 8/5/2013 11:01 AM, Brian Stansberry wrote:
>> On 8/5/13 9:20 AM, ssilvert(a)redhat.com wrote:
>>> On 8/5/2013 10:06 AM, Brian Stansberry wrote:
>>>> AIUI Darran's objection, this isn't particularly related to
domain mode.
>>>> It's that our jconsole plugin shouldn't be opening remoting
connections
>>>> to an arbitrary URL when the user has configured a direct connection.
>>> The intention here is that the CLI plugin should work when the user has
What is weird( I might be missing some important piece of intel here) is why there is
check against jboss remoting?
>>> NOT configured a direct remoting connection. You can
launch jconsole,
>>> click on the local server process, and CLI connects automatically.
It's
>>> much easier than typing the hard-to-remember remoting URL. It's just
>>> two clicks and you are done.
>>>> I agree with that and am fine with removing this feature from WF 8 and
>>>> just putting explanatory text in the tab.
>>>>
>>>> What if they have 2 servers on the machine, one 9990 and the other on
>>>> 9991 and they direct connect to the 9991 process?
Still, if the console managed to open non jboss remoting connection to AS, it should be
perfectly fine to query
AS for proper IP/Code? Only downside here is the authentication part, however this info is
not currently accessible in any way since JConsole code is quite restrictive.
>>> Don't we have the same kind of problem with
'jboss-cli -c' ? It does
>>> the right thing 99.9% of the time. It's just a convenience for the
>>> localhost developer.
>>>
>> The jboss-cli command is a WildFly command, unlike jconsole. A user can
>> read our documentation and understand what the impact of command line
>> options will be, and if they don't and get unexpected behavior I don't
>> think they'll be greatly surprised. The jconsole connection dialogue is
>> part of jconsole, not part of our plugin. A user cannot read standard
>> jconsole documentation and understand that with this particular mbean
>> server the direct connection option will result in a remoting connection
>> being opened to an arbitrary URL.
> In this case, jconsole actually IS a WildFly command. This won't work
> at all with the standard jconsole. You have to use our
> jconsole.sh/bat. So it should be covered by our docs.
>
I'm not buying this argument, because the jconsole connect dialogue is
the relevant part, not the launch script. But, no matter, since...
> Both 'jboss-cli -c' and jconsole cli plugin could give you an unexpected
> connection if you aren't careful. But this is rare and it's a tradeoff
> we've been willing to live with. I think Darran's suggestions get us
> closer to having something that gives the user the info they need while
> maintaining the ease of use.
Yes, those sound much better.
>>
>>>> On 8/5/13 8:34 AM, Jaikiran Pai wrote:
>>>>> It's this PR https://github.com/wildfly/wildfly/pull/4662 (which
we
>>>>> closed pending discussion).
>>>>>
>>>>> -Jaikiran
>>>>> On Monday 05 August 2013 06:46 PM, ssilvert(a)redhat.com wrote:
>>>>>> I can't find the PR you are referring to and I'm not
sure I fully
>>>>>> understand what the problem is.
>>>>>>
>>>>>> However, I can tell you that the original goal was to make this
work
>>>>>> just like 'jboss-cli -c' where if you don't specify
anything it will
>>>>>> try
>>>>>> to connect using our best guess of localhost:9990. If you can
make
>>>>>> that
>>>>>> smarter I don't see how it breaks backward compatibility.
It sounds
>>>>>> to
>>>>>> me like a good enhancement.
>>>>>>
>>>>>> But Darran's objection may have something to do with what
happens in a
>>>>>> domain environment. It's possible to connect jconsole to a
server
>>>>>> instance that is not the domain controller. In that case you
can't
>>>>>> (shouldn't?) connect CLI to it. So automatic discovery
might discover
>>>>>> something that is bogus from a CLI point of view.
>>>>>>
>>>>>> Stan
>>>>>>
>>>>>> On 8/5/2013 4:52 AM, Bartosz Baranowski wrote:
>>>>>>> Hey Guys.
>>>>>>>
>>>>>>> I missed last comment on related PR, hence I did not start
this
>>>>>>> thread.
>>>>>>>
>>>>>>> Currently JConsole plugin does something like:
>>>>>>>
>>>>>>> if(as7Remoting){
>>>>>>> //use
>>>>>>> } else {
>>>>>>> //discard connection
>>>>>>> // try to connect on hardcoded values locahost:9990
>>>>>>> }
>>>>>>>
>>>>>>>
https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jbos...
>>>>>>>
>>>>>>> Ive propesed a change to use existing connection to query
for proper
>>>>>>> IP/port pair of management interface and than attempt to
use
>>>>>>> cmdContext.connect. However it has been deemed as unfit fix
- even
>>>>>>> though it just addapts IP/port rather than make plugin
always use
>>>>>>> localhost:9990.
>>>>>>>
>>>>>>>
>>>>>>> Darran commented on this at some point:
>>>>>>>
>>>>>>> "However as I have said elsehwere I think this is
attempting to fix a
>>>>>>> 'feature' that should not exist in it's current
form"
>>>>>>> Trick is that this "feature" is there, its faulty,
but if its
>>>>>>> removed, it breaks backward compatibility.
>>>>>>>
>>>>>>> Also:
>>>>>>>
>>>>>>> Where jconsole is connected to the process locally I suggest
two
>>>>>>> alternatives: -
>>>>>>> - Add the CLI tab but with a clear message stating why
the CLI
>>>>>>> is not currently available, potentially add an
'Establish
>>>>>>> Connection' button to the tab with the capability
to prompt for
>>>>>>> a username and password if required and make use of
the
>>>>>>> discovered address.
>>>>>>> -Add an MBean that can handle management ops, the CLI
>>>>>>> integration can use that MBean regardless of the
connection
>>>>>>> method and would not require the establishment of
additional
>>>>>>> connections.
>>>>>>>
>>>>>>> So, any comments/suggestions?
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:37 p.m.
----- Original Message -----
From: "Darran Lofthouse"
<darran.lofthouse(a)jboss.com>
To: wildfly-dev(a)lists.jboss.org
Sent: Tuesday, August 6, 2013 2:31:22 PM
Subject: Re: [wildfly-dev] JConsole plugin - fallback and query for management address
On 06/08/13 13:27, Bartosz Baranowski wrote:
> What is weird( I might be missing some important piece of intel here) is
> why there is check against jboss remoting?
This one:
if (mbeanServerConn instanceof RemotingMBeanServerConnection) {
What check are you referring to?
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:38 p.m.
On 8/6/2013 8:27 AM, Bartosz Baranowski wrote:
----- Original Message -----
> From: "Brian Stansberry" <brian.stansberry(a)redhat.com>
> To: wildfly-dev(a)lists.jboss.org
> Sent: Monday, August 5, 2013 7:14:51 PM
> Subject: Re: [wildfly-dev] JConsole plugin - fallback and query for management
address
>
> On 8/5/13 10:58 AM, ssilvert(a)redhat.com wrote:
>> On 8/5/2013 11:01 AM, Brian Stansberry wrote:
>>> On 8/5/13 9:20 AM, ssilvert(a)redhat.com wrote:
>>>> On 8/5/2013 10:06 AM, Brian Stansberry wrote:
>>>>> AIUI Darran's objection, this isn't particularly related to
domain mode.
>>>>> It's that our jconsole plugin shouldn't be opening remoting
connections
>>>>> to an arbitrary URL when the user has configured a direct
connection.
>>>> The intention here is that the CLI plugin should work when the user has
What is weird( I might be missing some important piece of intel here) is why there is
check against jboss remoting?
If the user typed in a remoting URL then we already
have a remoting
connection. So we use the existing connection for CLI.
>>>> NOT configured a direct remoting connection. You can launch jconsole,
>>>> click on the local server process, and CLI connects automatically.
It's
>>>> much easier than typing the hard-to-remember remoting URL. It's
just
>>>> two clicks and you are done.
>>>>> I agree with that and am fine with removing this feature from WF 8
and
>>>>> just putting explanatory text in the tab.
>>>>>
>>>>> What if they have 2 servers on the machine, one 9990 and the other
on
>>>>> 9991 and they direct connect to the 9991 process?
Still, if the console managed to open non jboss remoting connection to AS, it should be
perfectly fine to query
AS for proper IP/Code? Only downside here is the authentication part, however this info
is not currently accessible in any way since JConsole code is quite restrictive.
>>>> Don't we have the same kind of problem with 'jboss-cli -c' ?
It does
>>>> the right thing 99.9% of the time. It's just a convenience for the
>>>> localhost developer.
>>>>
>>> The jboss-cli command is a WildFly command, unlike jconsole. A user can
>>> read our documentation and understand what the impact of command line
>>> options will be, and if they don't and get unexpected behavior I
don't
>>> think they'll be greatly surprised. The jconsole connection dialogue is
>>> part of jconsole, not part of our plugin. A user cannot read standard
>>> jconsole documentation and understand that with this particular mbean
>>> server the direct connection option will result in a remoting connection
>>> being opened to an arbitrary URL.
>> In this case, jconsole actually IS a WildFly command. This won't work
>> at all with the standard jconsole. You have to use our
>> jconsole.sh/bat. So it should be covered by our docs.
>>
> I'm not buying this argument, because the jconsole connect dialogue is
> the relevant part, not the launch script. But, no matter, since...
>
>> Both 'jboss-cli -c' and jconsole cli plugin could give you an unexpected
>> connection if you aren't careful. But this is rare and it's a tradeoff
>> we've been willing to live with. I think Darran's suggestions get us
>> closer to having something that gives the user the info they need while
>> maintaining the ease of use.
> Yes, those sound much better.
>
>>>>> On 8/5/13 8:34 AM, Jaikiran Pai wrote:
>>>>>> It's this PR https://github.com/wildfly/wildfly/pull/4662
(which we
>>>>>> closed pending discussion).
>>>>>>
>>>>>> -Jaikiran
>>>>>> On Monday 05 August 2013 06:46 PM, ssilvert(a)redhat.com wrote:
>>>>>>> I can't find the PR you are referring to and I'm not
sure I fully
>>>>>>> understand what the problem is.
>>>>>>>
>>>>>>> However, I can tell you that the original goal was to make
this work
>>>>>>> just like 'jboss-cli -c' where if you don't
specify anything it will
>>>>>>> try
>>>>>>> to connect using our best guess of localhost:9990. If you
can make
>>>>>>> that
>>>>>>> smarter I don't see how it breaks backward compatibility.
It sounds
>>>>>>> to
>>>>>>> me like a good enhancement.
>>>>>>>
>>>>>>> But Darran's objection may have something to do with what
happens in a
>>>>>>> domain environment. It's possible to connect jconsole to
a server
>>>>>>> instance that is not the domain controller. In that case you
can't
>>>>>>> (shouldn't?) connect CLI to it. So automatic discovery
might discover
>>>>>>> something that is bogus from a CLI point of view.
>>>>>>>
>>>>>>> Stan
>>>>>>>
>>>>>>> On 8/5/2013 4:52 AM, Bartosz Baranowski wrote:
>>>>>>>> Hey Guys.
>>>>>>>>
>>>>>>>> I missed last comment on related PR, hence I did not
start this
>>>>>>>> thread.
>>>>>>>>
>>>>>>>> Currently JConsole plugin does something like:
>>>>>>>>
>>>>>>>> if(as7Remoting){
>>>>>>>> //use
>>>>>>>> } else {
>>>>>>>> //discard connection
>>>>>>>> // try to connect on hardcoded values locahost:9990
>>>>>>>> }
>>>>>>>>
>>>>>>>>
https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jbos...
>>>>>>>>
>>>>>>>> Ive propesed a change to use existing connection to query
for proper
>>>>>>>> IP/port pair of management interface and than attempt to
use
>>>>>>>> cmdContext.connect. However it has been deemed as unfit
fix - even
>>>>>>>> though it just addapts IP/port rather than make plugin
always use
>>>>>>>> localhost:9990.
>>>>>>>>
>>>>>>>>
>>>>>>>> Darran commented on this at some point:
>>>>>>>>
>>>>>>>> "However as I have said elsehwere I think this is
attempting to fix a
>>>>>>>> 'feature' that should not exist in it's
current form"
>>>>>>>> Trick is that this "feature" is there, its
faulty, but if its
>>>>>>>> removed, it breaks backward compatibility.
>>>>>>>>
>>>>>>>> Also:
>>>>>>>>
>>>>>>>> Where jconsole is connected to the process locally I
suggest two
>>>>>>>> alternatives: -
>>>>>>>> - Add the CLI tab but with a clear message stating
why the CLI
>>>>>>>> is not currently available, potentially add an
'Establish
>>>>>>>> Connection' button to the tab with the
capability to prompt for
>>>>>>>> a username and password if required and make use of
the
>>>>>>>> discovered address.
>>>>>>>> -Add an MBean that can handle management ops, the
CLI
>>>>>>>> integration can use that MBean regardless of the
connection
>>>>>>>> method and would not require the establishment of
additional
>>>>>>>> connections.
>>>>>>>>
>>>>>>>> So, any comments/suggestions?
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:54 p.m.
On 06/08/13 13:37, Bartosz Baranowski wrote:
----- Original Message -----
> From: "Darran Lofthouse" <darran.lofthouse(a)jboss.com>
> To: wildfly-dev(a)lists.jboss.org
> Sent: Tuesday, August 6, 2013 2:31:22 PM
> Subject: Re: [wildfly-dev] JConsole plugin - fallback and query for management
address
>
>
>
> On 06/08/13 13:27, Bartosz Baranowski wrote:
>
>> What is weird( I might be missing some important piece of intel here) is
>> why there is check against jboss remoting?
This one:
if (mbeanServerConn instanceof RemotingMBeanServerConnection) {
The purpose of that check is to see if we already have a Remoting
connection established to the server for JMX, if so the same connection
can be used for the management connection.
That is one of the reasons I am not a fan of just opening a Remoting
connection automatically - if they chose to use Remoting we make use of
that same connection for two different purposes - if they choose not to
use Remoting we open a Remoting connection anyway. But a 'Connect'
button on the CLI tab would take care of that.
>
> What check are you referring to?
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
3:32 p.m.
On 8/6/2013 8:54 AM, Darran Lofthouse wrote:
On 06/08/13 13:37, Bartosz Baranowski wrote:
>
> ----- Original Message -----
>> From: "Darran Lofthouse" <darran.lofthouse(a)jboss.com>
>> To: wildfly-dev(a)lists.jboss.org
>> Sent: Tuesday, August 6, 2013 2:31:22 PM
>> Subject: Re: [wildfly-dev] JConsole plugin - fallback and query for management
address
>>
>>
>>
>> On 06/08/13 13:27, Bartosz Baranowski wrote:
>>
>>> What is weird( I might be missing some important piece of intel here) is
>>> why there is check against jboss remoting?
>
> This one:
> if (mbeanServerConn instanceof RemotingMBeanServerConnection) {
The purpose of that check is to see if we already have a Remoting
connection established to the server for JMX, if so the same connection
can be used for the management connection.
That is one of the reasons I am not a fan of just opening a Remoting
connection automatically - if they chose to use Remoting we make use of
that same connection for two different purposes - if they choose not to
use Remoting we open a Remoting connection anyway. But a 'Connect'
button on the CLI tab would take care of that.
Instead of a connect button on the
CLI tab, I'd rather see something
like this:
if (remoting connection exists) {
use existing connection
} else {
display CLI connection dialog
}
The connection dialog would have the defaults already filled in. Since
those defaults are almost always what you want, you have only cost the
user a single click. The dialog can also contain a "Don't use CLI"
button. Then the CLI the tab won't be displayed.
Bonus points if you detect the existence of jboss-cli.xml and get your
defaults from there.
>
>> What check are you referring to?
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:36 p.m.
----- Original Message -----
From: "Darran Lofthouse"
<darran.lofthouse(a)jboss.com>
To: "Bartosz Baranowski" <bbaranow(a)redhat.com>
Cc: "Darran Lofthouse" <darran.lofthouse(a)jboss.com>,
wildfly-dev(a)lists.jboss.org
Sent: Tuesday, August 6, 2013 2:54:44 PM
Subject: Re: [wildfly-dev] JConsole plugin - fallback and query for management address
On 06/08/13 13:37, Bartosz Baranowski wrote:
>
>
> ----- Original Message -----
>> From: "Darran Lofthouse" <darran.lofthouse(a)jboss.com>
>> To: wildfly-dev(a)lists.jboss.org
>> Sent: Tuesday, August 6, 2013 2:31:22 PM
>> Subject: Re: [wildfly-dev] JConsole plugin - fallback and query for
>> management address
>>
>>
>>
>> On 06/08/13 13:27, Bartosz Baranowski wrote:
>>
>>> What is weird( I might be missing some important piece of intel here) is
>>> why there is check against jboss remoting?
>
>
> This one:
> if (mbeanServerConn instanceof RemotingMBeanServerConnection) {
The purpose of that check is to see if we already have a Remoting
connection established to the server for JMX, if so the same connection
can be used for the management connection.
That is one of the reasons I am not a fan of just opening a Remoting
connection automatically - if they chose to use Remoting we make use of
that same connection for two different purposes - if they choose not to
use Remoting we open a Remoting connection anyway. But a 'Connect'
button on the CLI tab would take care of that.
Ok, let me rephrase. Why there is any distinction between regular connection vs
jboss remoting connection class?
>
>
>>
>> What check are you referring to?
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
3:58 p.m.
On 8/6/2013 9:36 AM, Bartosz Baranowski wrote:
----- Original Message -----
> From: "Darran Lofthouse" <darran.lofthouse(a)jboss.com>
> To: "Bartosz Baranowski" <bbaranow(a)redhat.com>
> Cc: "Darran Lofthouse" <darran.lofthouse(a)jboss.com>,
wildfly-dev(a)lists.jboss.org
> Sent: Tuesday, August 6, 2013 2:54:44 PM
> Subject: Re: [wildfly-dev] JConsole plugin - fallback and query for management
address
>
> On 06/08/13 13:37, Bartosz Baranowski wrote:
>>
>> ----- Original Message -----
>>> From: "Darran Lofthouse" <darran.lofthouse(a)jboss.com>
>>> To: wildfly-dev(a)lists.jboss.org
>>> Sent: Tuesday, August 6, 2013 2:31:22 PM
>>> Subject: Re: [wildfly-dev] JConsole plugin - fallback and query for
>>> management address
>>>
>>>
>>>
>>> On 06/08/13 13:27, Bartosz Baranowski wrote:
>>>
>>>> What is weird( I might be missing some important piece of intel here) is
>>>> why there is check against jboss remoting?
>>
>> This one:
>> if (mbeanServerConn instanceof RemotingMBeanServerConnection) {
> The purpose of that check is to see if we already have a Remoting
> connection established to the server for JMX, if so the same connection
> can be used for the management connection.
>
> That is one of the reasons I am not a fan of just opening a Remoting
> connection automatically - if they chose to use Remoting we make use of
> that same connection for two different purposes - if they choose not to
> use Remoting we open a Remoting connection anyway. But a 'Connect'
> button on the CLI tab would take care of that.
>
Ok, let me rephrase. Why there is any distinction between regular connection vs jboss
remoting connection class?
When you launch jconsole you get a dialog that shows your
local
processes. You have the option of clicking on one of those processes or
typing in a connection URL. If you type in a connection URL and it is a
remoting URL then you are all set. CLI can just use that remoting
connection.
If you click on a process then you are not using a remoting connection.
But you need a remoting connection in order to send CLI commands using
the CLI API. So if you want to use CLI in that case, a remoting
connection must be created. Right now it does this automatically, but
it would be better if the user had a little more feedback and control in
the matter.
Darran has also proposed using an MBean for executing CLI commands. In
some ways that would be the best solution because you don't need a
remoting connection. You could always use the existing connection 100%
of the time. The problem is that this solution would take a long time
to implement because you get less help from the CLI API. And, I don't
think we want an MBean to be a full management endpoint.
>>
>>> What check are you referring to?
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
5:36 p.m.
On 8/6/13 8:58 AM, ssilvert(a)redhat.com wrote:
Darran has also proposed using an MBean for executing CLI commands. In
some ways that would be the best solution because you don't need a
remoting connection. You could always use the existing connection 100%
of the time. The problem is that this solution would take a long time
to implement because you get less help from the CLI API. And, I don't
think we want an MBean to be a full management endpoint.
+1. My gut instinct is to avoid this.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
5:42 p.m.
On 06/08/13 14:32, ssilvert(a)redhat.com wrote:
On 8/6/2013 8:54 AM, Darran Lofthouse wrote:
> On 06/08/13 13:37, Bartosz Baranowski wrote:
>>
>> ----- Original Message -----
>>> From: "Darran Lofthouse" <darran.lofthouse(a)jboss.com>
>>> To: wildfly-dev(a)lists.jboss.org
>>> Sent: Tuesday, August 6, 2013 2:31:22 PM
>>> Subject: Re: [wildfly-dev] JConsole plugin - fallback and query for
management address
>>>
>>>
>>>
>>> On 06/08/13 13:27, Bartosz Baranowski wrote:
>>>
>>>> What is weird( I might be missing some important piece of intel here) is
>>>> why there is check against jboss remoting?
>>
>> This one:
>> if (mbeanServerConn instanceof RemotingMBeanServerConnection) {
> The purpose of that check is to see if we already have a Remoting
> connection established to the server for JMX, if so the same connection
> can be used for the management connection.
>
> That is one of the reasons I am not a fan of just opening a Remoting
> connection automatically - if they chose to use Remoting we make use of
> that same connection for two different purposes - if they choose not to
> use Remoting we open a Remoting connection anyway. But a 'Connect'
> button on the CLI tab would take care of that.
Instead of a connect button on the CLI tab, I'd rather see something
like this:
if (remoting connection exists) {
use existing connection
} else {
display CLI connection dialog
}
The connection dialog would have the defaults already filled in. Since
those defaults are almost always what you want, you have only cost the
user a single click. The dialog can also contain a "Don't use CLI"
button. Then the CLI the tab won't be displayed.
I was kind of thinking this dialogue could be built into the tab so
until they switch to the tab they don't even need to think about the CLI
but overall don't have a strong view about that.
Whichever way I agree in a dialogue that is a pre-populated as possible.
Bonus points if you detect the existence of jboss-cli.xml and get
your
defaults from there.
>
>>
>>> What check are you referring to?
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
5:48 p.m.
On 06/08/13 16:36, Brian Stansberry wrote:
On 8/6/13 8:58 AM, ssilvert(a)redhat.com wrote:
> Darran has also proposed using an MBean for executing CLI
commands. In
> some ways that would be the best solution because you don't need a
> remoting connection. You could always use the existing connection 100%
> of the time. The problem is that this solution would take a long time
> to implement because you get less help from the CLI API. And, I don't
> think we want an MBean to be a full management endpoint.
+1. My gut instinct is to avoid this.
Yeah I only suggested that one to maintain the single connection
approach but if we keep going we will keep going round in circles
integrating JMX with management and management with JMX ;-)
5:56 p.m.
On 8/6/2013 11:42 AM, Darran Lofthouse wrote:
On 06/08/13 14:32, ssilvert(a)redhat.com wrote:
> On 8/6/2013 8:54 AM, Darran Lofthouse wrote:
>> On 06/08/13 13:37, Bartosz Baranowski wrote:
>>> ----- Original Message -----
>>>> From: "Darran Lofthouse" <darran.lofthouse(a)jboss.com>
>>>> To: wildfly-dev(a)lists.jboss.org
>>>> Sent: Tuesday, August 6, 2013 2:31:22 PM
>>>> Subject: Re: [wildfly-dev] JConsole plugin - fallback and query for
management address
>>>>
>>>>
>>>>
>>>> On 06/08/13 13:27, Bartosz Baranowski wrote:
>>>>
>>>>> What is weird( I might be missing some important piece of intel here)
is
>>>>> why there is check against jboss remoting?
>>> This one:
>>> if (mbeanServerConn instanceof RemotingMBeanServerConnection) {
>> The purpose of that check is to see if we already have a Remoting
>> connection established to the server for JMX, if so the same connection
>> can be used for the management connection.
>>
>> That is one of the reasons I am not a fan of just opening a Remoting
>> connection automatically - if they chose to use Remoting we make use of
>> that same connection for two different purposes - if they choose not to
>> use Remoting we open a Remoting connection anyway. But a 'Connect'
>> button on the CLI tab would take care of that.
> Instead of a connect button on the CLI tab, I'd rather see something
> like this:
> if (remoting connection exists) {
> use existing connection
> } else {
> display CLI connection dialog
> }
>
> The connection dialog would have the defaults already filled in. Since
> those defaults are almost always what you want, you have only cost the
> user a single click. The dialog can also contain a "Don't use CLI"
> button. Then the CLI the tab won't be displayed.
I was kind of thinking this dialogue could be built into the tab so
until they switch to the tab they don't even need to think about the CLI
but overall don't have a strong view about that.
If you build it into the main
CLI GUI code then you are asking for a
little more work. I'd love to see CLI GUI have a connection management
UI. There is a lot you could do in that area. I guess it just depends
on how much time Bartosz wants to spend.
With the dialog, it's just a simple addition to the jconsole plugin. It
doesn't affect the rest of CLI GUI.
Whichever way I agree in a dialogue that is a pre-populated as possible.
> Bonus points if you detect the existence of jboss-cli.xml and get your
> defaults from there.
>
>>>> What check are you referring to?
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3909
days inactive
3910
days old
25 comments
5 participants
participants (5)
-
Bartosz Baranowski -
Brian Stansberry -
Darran Lofthouse -
Jaikiran Pai -
ssilvert＠redhat.com