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

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 &gt;&gt;&gt;&lt;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 &gt;&gt;wildfly-dev(a)lists.jboss.org >>https://lists.jboss.org/mailman/listinfo/wildfly-dev