[wildfly-dev] Change CLI to Default to Remoting
Brian Stansberry
brian.stansberry at redhat.com
Wed Nov 6 13:57:31 EST 2013
This looks good; thanks for writing it up.
The only change I want to see is what we discussed on this branch of
this thread:
http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000464.html
On 11/6/13 5:39 AM, Darran Lofthouse wrote:
> 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
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
More information about the wildfly-dev
mailing list