On 05/08/13 15:20, 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.
No the CLI has configuration to specify which host to connect to.
Secondly the CLI will enter into an interactive prompt with the end user
if authentication is required.
>
> 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