[wildfly-dev] Change CLI to Default to Remoting

[Max Rydahl Andersen]

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