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

Access control did take priority for a while, anyway back on clearing out some tasks for WildFly now so this one has popped up again with some other related issues. I have put together a small article here on how we should handle addresses, especially addresses that are not complete here: - https://community.jboss.org/wiki/CLIConnections-AddressHandling The last time this was discussed one concern was if we wanted to drive the port number from the protocol this didn't cover the scenario where users are used to 'localhost:9999' - this is covered by defining an alias to map that address. Regards, Darran Lofthouse. On 06/08/13 11:09, 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 > > 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(a)jboss.com <mailto:darran.lofthouse@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(a)lists.jboss.org <mailto:wildfly-dev@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