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 ?
CLI will first look
for it in the current directory. Then it will try
<JBOSS_HOME>/bin. There is a default copy of the file in <JBOSS_HOME>/bin.
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(a)jboss.com
<mailto:darran.lofthouse@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(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
>>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev