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
>