Re: [wildfly-dev] Change CLI to Default to Remoting

This sounds reasonable, and improves configurability. But it really doesn't solve the compatibility problem. If the user specifies port 9999 and they haven't clearly specified the protocol, the CLI needs to use remote://. I don't agree that the port offset problem is significant. If you can make the common case just work and not break people, you do that; you don't leave them broken because you can't handle some other cases.

On 7/10/13 5:58 AM, Darran Lofthouse wrote: > Actually I think the better option could be the following: - > > Add a new default-protocol to the CLI configuration. The purpose of > this will be if an address is specified without a scheme/protocol this > default will be used. > > This is separate from the pick and mix default host which will only be > used as the address to connect to if no address is specified. > > If no port is specified then the port will be decided based on the > entered scheme or default if non specified. > remote:// / remoting:// will be 9999 > http-remoting:// will be 9990 > https-remoting:// will be 9443 (Although there is some demand to > change this default) > > This will still leave room in the future to add support aliases in the > jboss-cli, so 'connect name' will: - > - Search a list if aliases for a match on name, if so use the host > definition. > - If no match assume it is a host name, use the default-protocol and > assign the default port. > > WildFly 8 can then continue on the http-upgrade is the way to go path > and set the default protocol to http-upgrade, EAP 7 in the future can > tweak the config back to default to remoting:// if existing connect > commands against older installations need to be supported. > > This does not cover choosing a scheme/protocol based on the port number > which I think will be just problematic as soon as port offsets are > introduced but one final option if support for aliases is added would be > on 'connect host:port' search for an alias with this pair and pick up > the protocol from that. > > Regards, > Darran Lofthouse. > > > On 09/07/13 17:18, Darran Lofthouse wrote: >> Now that we have multiple protocols available for use from the CLI I >> don't see that it should be a big issue for clients wanting to use the >> HTTP Upgrade to specify it in their address. >> >> After all they need to specify the correct form of 'http-remoting' and >> 'https-remoting' depending on the SSL setting of the server. >> >> The problem with any assumptions based on ports is that it makes the >> behavior inconsistent once connecting to a server with port offsets - >> and these servers could quite possibly be older version. >> >> This does also introduce the issue that maybe we should support http:// >> and https:// in the connection address supported by the CLI. It would >> make the addresses easier for end users to understand although it would >> not be an option to access the HTTP interface directly. >> >> Regards, >> Darran Lofthouse. >> >> >> On 09/07/13 17:03, Jason Greene wrote: >>> -1 to the CLI assuming a remoting connection. We are likely to turn off the remoting port in the default config before Final. >>> >>> A good solution would IMO be something like a combination of: >>> >>> 1. If no port is specified try http remoting on 9990, then fallback to 9999 printing a message >>> 2. If 9999 is specified assume traditional remoting >>> 3. All other ports assume http-remoting >>> >>> On Jul 9, 2013, at 10:22 AM, Darran Lofthouse <darran.lofthouse(a)jboss.com&gt; 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> -- >>> Jason T. Greene >>> WildFly Lead / JBoss EAP Platform Architect >>> JBoss, a division of Red Hat >>> >> _______________________________________________ >> 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 >