[wildfly-dev] Change CLI to Default to Remoting
Darran Lofthouse
darran.lofthouse at jboss.com
Wed Nov 6 06:39:00 EST 2013
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 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
More information about the wildfly-dev
mailing list