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

One additional benefit I realised regarding this approach. Say a user has a load of scripts that use 'connect localhost:9999' by using the alias mappings in the configuration they can potentially map this over to 'http-remoting://localhost:9990' if they choose to disable the native management interface. Regards, Darran Lofthouse. On 05/11/13 18:16, Darran Lofthouse wrote: > 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 _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev