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

Tue Aug 6 08:27:52 EDT 2013

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

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