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

Mon Aug 5 13:14:51 EDT 2013

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
>>> 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 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