[wildfly-dev] Change CLI to Default to Remoting

[ssilvert at redhat.com]

On 8/6/2013 11:05 AM, Max Rydahl Andersen wrote:
> On Tue, Aug 06, 2013 at 11:09:31AM +0100, Darran Lofthouse wrote:
>> Access control has taken priority at the moment but I will see if I 
>> can get a change to put something together to summarize a set of rules 
>> for determining exactly how to connect.
>>
>> Recently issues have also been identified for connections from 
>> jconsole, they are not directly related but do show another client 
>> affected.
>>
>> One aspect of this discussion was how the configuration in 
>> jboss-cli.xml can be used / expanded on to determine how to connect - 
>> I wonder if we could make use of a single management client 
>> configuration that could be used by all management clients when making 
>> connection decisions rather than just the CLI - e.g. 
>> wildfly-management.xml
> I haven't seen jboss-cli.xml before...where is it located ?
CLI will first look for it in the current directory.  Then it will try
<JBOSS_HOME>/bin.  There is a default copy of the file in <JBOSS_HOME>/bin.

>
> btw. i like the idea about a shared configuration for connection info.
>
> /max
>
>> Regards,
>> Darran Lofthouse.
>>
>> On 06/08/13 09:01, Max Rydahl Andersen wrote:
>>> I know this is an old thread but been on pto, so....
>>>
>>> This whole discussion also relates to how tools like eclipse, intellij,
>>> netbeans,
>>> arquillian, mvn plugin etc. are going to handle the
>>> communication/protocol naming.
>>>
>>> Have there been a  conclusion on how this can/will be solved on the CLI ?
>>>
>>> I would then like to see if we could come up with a best way of how to
>>> do it from at least eclipse, mvn and arquillian since I think it would
>>> be good if we started
>>> using the same syntax for connection parameters and defaulting (at least
>>> as much
>>> as our different usecases allows)
>>>
>>> /max
>>>
>>> On Wed, Jul 10, 2013 at 11:28:33AM +0100, Darran Lofthouse wrote:
>>>> On 09/07/13 22:45, Stuart Douglas wrote:
>>>>> I don't think this is really practical, is once we remove the remoting
>>>>> port from the config it means that the CLI will not connect to new
>>>>> servers unless you explicitly specify the port.
>>>> That may be the case if we rely on ports to decide the protocol.
>>>>
>>>>> This has its own
>>>>> backward compatibility problems, as now your scripts will break if you
>>>>> have upgraded you cluster to WF8.
>>>> I think the CLI configuration has become confused in this area, we have
>>>> a default host block which defined the host if no address is specified
>>>> to connect but this block is also used as a pick and mix to extract a
>>>> port from if no port is specified.
>>>>
>>>> Personally I think general defaults and a default host are actually two
>>>> different things.
>>>>
>>>> However this is all becoming back to front, elswhere it is standard
>>>> practice to specify the scheme in order to omit a default port - not
>>>> take a port and try and work out the scheme.
>>>>
>>>>> Also it is possible to set the default protocol in jboss-cli.xml, if
>>>>> your scripts do break because of this change it is basically a one
>>>>> line fix.
>>>> Actually it isn't, if you specify any part of the address it has been
>>>> hard coded that the protocol is http-remoting.
>>>>
>>>>> On Wed, Jul 10, 2013 at 1:22 AM, Darran Lofthouse
>>>>> <darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com>> wrote:
>>>>>
>>>>>    Hello all,
>>>>>
>>>>>    I am currently working on the following issue: -
>>>>>
>>>>>    https://issues.jboss.org/browse/WFLY-1664
>>>>>
>>>>>    Recent changes to the CLI mean that it is assuming unless told
>>>>> otherwise
>>>>>    that a HTTP Upgrade is going to be used when connecting to the
>>>>> server,
>>>>>    this means that command already used in scripts to connect to
>>>>> servers
>>>>>    are going to fail unless the scheme is included in the URI.
>>>>>
>>>>>    I chatted with David to see if there were any options to auto detect
>>>>>    this and fall back to pure Remoting if the remote side of the
>>>>> connection
>>>>>    is pure Remoting - however of the two options available they were
>>>>> both
>>>>>    fairly hacky or unreliable.
>>>>>
>>>>>    So the alternative is to drop the CLI back to assuming a pure
>>>>> Remoting
>>>>>    connection unless told otherwise.
>>>>>       - Calling connect or starting with -c will still use
>>>>> http-remoting
>>>>>    against the local server as that is defined in the jboss-cli.xml
>>>>>       - Calling connect or --controller with a host and port will
>>>>> assume
>>>>>    connecting directly to remoting.
>>>>>       - Users wanting HTTP upgrade to other servers will need to
>>>>> specify
>>>>>    http-remoting or https-remoting as the scheme when specifying the
>>>>> remote
>>>>>    address.
>>>>>
>>>>>    One other idea that I have had for the CLI if end users do want the
>>>>>    parameter to the connect command to be as short as possible is to
>>>>> add
>>>>>    multiple host aliases to the jboss-cli.xml - that way the
>>>>> protocol host
>>>>>    and port can be specified in the config and the alias passed to the
>>>>>    connect command.  Additionally this would allow us to place
>>>>> different
>>>>>    SSL configuration against each host but.
>>>>>
>>>>>    Regards,
>>>>>    Darran Lofthouse.
>>>>>
>>>>>    _______________________________________________
>>>>>    wildfly-dev mailing list
>>>>>    wildfly-dev at lists.jboss.org <mailto: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