It's this PR
https://github.com/wildfly/wildfly/pull/4662 (which
we
closed pending discussion).
I see now. Perhaps Darran can elaborate on his
objections. Security
concerns maybe?
BTW, I think you meant to remove line 117 of your commit:
if(true)throw new IOException();
-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