[wildfly-dev] Change CLI to Default to Remoting

Darran Lofthouse darran.lofthouse at jboss.com
Wed Nov 6 14:09:34 EST 2013


On 06/11/13 18:57, Brian Stansberry wrote:
> 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

Ok I will add that, the aliases would cover localhost:9999 but I realise 
we were talking about assuming 'remoting://' for all addresses on port 
9999 so I will support that as well.

> 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
>>
>
>


More information about the wildfly-dev mailing list