[wildfly-dev] JConsole plugin - fallback and query for management address

ssilvert at redhat.com ssilvert at redhat.com
Tue Aug 6 08:38:38 EDT 2013 

On 8/6/2013 8:27 AM, Bartosz Baranowski wrote:
>
> ----- Original Message -----
>> From: "Brian Stansberry" <brian.stansberry at redhat.com>
>> To: wildfly-dev at 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 at redhat.com wrote:
>>> On 8/5/2013 11:01 AM, Brian Stansberry wrote:
>>>> On 8/5/13 9:20 AM, ssilvert at 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 at 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/jboss/as/cli/gui/JConsoleCLIPlugin.java#L100
>>>>>>>>>
>>>>>>>>> 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 at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

More information about the wildfly-dev mailing list