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
>