As WildFly has now been changed so that management operations can make use of HTTP Upgrade support through Undertow the decisions within the CLI have become more complex when deciding how to create a URI involving a scheme, a host name and a port number, based on a discussion earlier this year this article is to describe an approach for address resolution.
As it stands today the following configuration is possible within the jboss-cli.xml configuration file: -
<!-- The default controller to connect to when 'connect' command is executed w/o arguments --> <default-controller> <protocol>http-remoting</protocol> <host>localhost</host> <port>9990</port> </default-controller>
The way that this is currently being used is if the user of the CLI enters an address if any of these values are omitted from the address then the default will be used, this causes complications as there is no check that the value from the config should even be used with the address specified e.g it has been common to specify localhost:9999 which is only compatible with the 'remoting' protocol but now by using the protocol from this block http-remoting gets used.
A couple of Jira issues exist to tackle this issue WFLY-1664 and WFLY-1850, the first of these issues covers the backwards compatibility problem - the second issue covers an enhancement to the CLI to allow aliases to be defined for connections to servers.
Under these tasks I am planning to change the configuration as follows: -
<default-protocol use-legacy-override="true">http-remoting</default-protocol> <!-- The default controller to connect to when 'connect' command is executed w/o arguments --> <default-controller> <protocol>http-remoting</protocol> <host>localhost</host> <port>9990</port> </default-controller> <controllers> <controller name="ServerOne"> <protocol>remoting</protocol> <host>192.168.3.45</host> <port>9999</port> </controller> <controller name="ServerTwo"> <protocol>http-remoting</protocol> <host>192.168.3.46</host> </controller> <controller name="127.0.0.1:9999"> <protocol>remoting</protocol> <host>127.0.0.1</host> <port>9999</port> </controller> <controller name="localhost:9999"> <protocol>remoting</protocol> <host>localhost</host> <port>9999</port> </controller> </controllers>
Note: If the CLI is started with the arguments --controller= or controller= then the value specified with this argument overrides the default-controller definition from the configuration.
If there is no controller specified on the command line and their is no default-controller defined within the configuration (or the configuration does not exist) then the default controller will be assumed to be http-remoting://localhost:9990.
Address Handling Rules
When an address is supplied to 'connect' within the CLI the following approach will be taken to determine the 3 parts of the URI: -
- Compare the name supplied with the name specified for each 'controller', if there is a match treat the address as an alias and use the values defined for the controller.
At this point either we have some parts of the total URI from the controller definition or we will parse the address entered into it's constituent parts.
- If we do not have a protocol then assume the protocol intended is the one specified in the 'default-protocol' element, or, if we know the port is '9999' and the default-protocol element's "use-legacy-override" attribute is "true", use "remoting://".
- Verify we have a host, that is always mandatory.
- If we have a port then use it, otherwise select a port based on the protocol according to the following table: -
|remote:// or remoting://||9999|
If no address was supplied to the connect command then the three values specified as 'default-controller' will be used.
When WFLY-1664 was previously discussed one main concern was that we should avoid breaking scripts used to administer AS7 that may also be used against WildFly so if a script is using localhost:9999 we were discussing a match on this address to default to remoting, as illustrated above we can achieve this by defining a couple of aliases without needing any special handling. If users have additional addresses that break then they can also define aliases in this style. Finally they also have the opportunity to override the default protocol if they have a large number of legacy servers that they need to communicate with.