[wildfly-dev] Change CLI to Default to Remoting

Tue Aug 6 11:05:26 EDT 2013

On Tue, Aug 06, 2013 at 11:09:31AM +0100, 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

I haven't seen jboss-cli.xml before...where is it located ?

btw. i like the idea about a shared configuration for connection info.

/max

>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 at jboss.com <mailto:darran.lofthouse at 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 at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>>>    https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>_______________________________________________
>>>wildfly-dev mailing list
>>>wildfly-dev at lists.jboss.org
>>>https://lists.jboss.org/mailman/listinfo/wildfly-dev