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 https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 09/07/13 16:57, Brian Stansberry wrote: > Sounds fine. I'd be fine with a simple heuristic based on the port as > well, so --controller=localhost:9990 would default to http-remoting. I can add that if we want but just thinking if it would cause confusion if it suddenly stops working once they start trying to connect to a second instance with offset ports. If they do not specify any address at all it will default to the address in the config which is http-remoting by default. _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

From: "Bruno Georges" <bgeorges(a)redhat.com&gt; To: "Brian Stansberry" <brian.stansberry(a)redhat.com&gt; Cc: wildfly-dev(a)lists.jboss.org Sent: Wednesday, July 10, 2013 6:33:39 AM Subject: Re: [wildfly-dev] Change CLI to Default to Remoting +1 Sent from my iPhone On 10 Jul, 2013, at 0:41, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > There's going to be confusion no matter what we do. > > The thing I care about most is if people run old scripts or follow old > instructions that their teams have written up that say > --controller=XXX:9999 it should just work. We shouldn't force people to > rewrite their scripts and processes just because we decided port > reduction was more important than compatibility. > > Remember also that people will use the new CLI binary to manage legacy > servers where HTTP upgrade is not an option. So even if by default WF > isn't using 9999, there will be need for the CLI to deal cleanly with 9999. > > (Most of the above wasn't directly in response to your last comment.) > > On 7/9/13 11:03 AM, Darran Lofthouse wrote: >> On 09/07/13 16:57, Brian Stansberry wrote: >>> Sounds fine. I'd be fine with a simple heuristic based on the port as >>> well, so --controller=localhost:9990 would default to http-remoting. >> >> I can add that if we want but just thinking if it would cause confusion >> if it suddenly stops working once they start trying to connect to a >> second instance with offset ports. >> >> If they do not specify any address at all it will default to the address >> in the config which is http-remoting by default. >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > -- > Brian Stansberry > Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > 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

-1 to the CLI assuming a remoting connection. We are likely to turn off the remoting port in the default config before Final. A good solution would IMO be something like a combination of: 1. If no port is specified try http remoting on 9990, then fallback to 9999 printing a message 2. If 9999 is specified assume traditional remoting 3. All other ports assume http-remoting On Jul 9, 2013, at 10:22 AM, Darran Lofthouse <darran.lofthouse(a)jboss.com&gt; 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 > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

Actually I think the better option could be the following: - Add a new default-protocol to the CLI configuration. The purpose of this will be if an address is specified without a scheme/protocol this default will be used. This is separate from the pick and mix default host which will only be used as the address to connect to if no address is specified. If no port is specified then the port will be decided based on the entered scheme or default if non specified. remote:// / remoting:// will be 9999 http-remoting:// will be 9990 https-remoting:// will be 9443 (Although there is some demand to change this default) This will still leave room in the future to add support aliases in the jboss-cli, so 'connect name' will: - - Search a list if aliases for a match on name, if so use the host definition. - If no match assume it is a host name, use the default-protocol and assign the default port. WildFly 8 can then continue on the http-upgrade is the way to go path and set the default protocol to http-upgrade, EAP 7 in the future can tweak the config back to default to remoting:// if existing connect commands against older installations need to be supported. This does not cover choosing a scheme/protocol based on the port number which I think will be just problematic as soon as port offsets are introduced but one final option if support for aliases is added would be on 'connect host:port' search for an alias with this pair and pick up the protocol from that. Regards, Darran Lofthouse. On 09/07/13 17:18, Darran Lofthouse wrote: > Now that we have multiple protocols available for use from the CLI I > don't see that it should be a big issue for clients wanting to use the > HTTP Upgrade to specify it in their address. > > After all they need to specify the correct form of 'http-remoting' and > 'https-remoting' depending on the SSL setting of the server. > > The problem with any assumptions based on ports is that it makes the > behavior inconsistent once connecting to a server with port offsets - > and these servers could quite possibly be older version. > > This does also introduce the issue that maybe we should support http:// > and https:// in the connection address supported by the CLI. It would > make the addresses easier for end users to understand although it would > not be an option to access the HTTP interface directly. > > Regards, > Darran Lofthouse. > > > On 09/07/13 17:03, Jason Greene wrote: >> -1 to the CLI assuming a remoting connection. We are likely to turn off the remoting port in the default config before Final. >> >> A good solution would IMO be something like a combination of: >> >> 1. If no port is specified try http remoting on 9990, then fallback to 9999 printing a message >> 2. If 9999 is specified assume traditional remoting >> 3. All other ports assume http-remoting >> >> On Jul 9, 2013, at 10:22 AM, Darran Lofthouse <darran.lofthouse(a)jboss.com&gt; 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 >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> > _______________________________________________ > 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

On 11/07/13 05:10, Brian Stansberry wrote: > This sounds reasonable, and improves configurability. But it really > doesn't solve the compatibility problem. > > If the user specifies port 9999 and they haven't clearly specified the > protocol, the CLI needs to use remote://. I don't agree that the port > offset problem is significant. If you can make the common case just work > and not break people, you do that; you don't leave them broken because > you can't handle some other cases. Ok so if no scheme is specified, first check if it is one of the three known ports 9999, 9990, or 9443 and assign the appropriate scheme, if there is no match on a port then use the configured default.

> > On 7/10/13 5:58 AM, Darran Lofthouse wrote: >> Actually I think the better option could be the following: - >> >> Add a new default-protocol to the CLI configuration. The purpose of >> this will be if an address is specified without a scheme/protocol this >> default will be used. >> >> This is separate from the pick and mix default host which will only be >> used as the address to connect to if no address is specified. >> >> If no port is specified then the port will be decided based on the >> entered scheme or default if non specified. >> remote:// / remoting:// will be 9999 >> http-remoting:// will be 9990 >> https-remoting:// will be 9443 (Although there is some demand to >> change this default) >> >> This will still leave room in the future to add support aliases in the >> jboss-cli, so 'connect name' will: - >> - Search a list if aliases for a match on name, if so use the host >> definition. >> - If no match assume it is a host name, use the default-protocol and >> assign the default port. >> >> WildFly 8 can then continue on the http-upgrade is the way to go path >> and set the default protocol to http-upgrade, EAP 7 in the future can >> tweak the config back to default to remoting:// if existing connect >> commands against older installations need to be supported. >> >> This does not cover choosing a scheme/protocol based on the port number >> which I think will be just problematic as soon as port offsets are >> introduced but one final option if support for aliases is added would be >> on 'connect host:port' search for an alias with this pair and pick up >> the protocol from that. >> >> Regards, >> Darran Lofthouse. >> >> >> On 09/07/13 17:18, Darran Lofthouse wrote: >>> Now that we have multiple protocols available for use from the CLI I >>> don't see that it should be a big issue for clients wanting to use the >>> HTTP Upgrade to specify it in their address. >>> >>> After all they need to specify the correct form of 'http-remoting' and >>> 'https-remoting' depending on the SSL setting of the server. >>> >>> The problem with any assumptions based on ports is that it makes the >>> behavior inconsistent once connecting to a server with port offsets - >>> and these servers could quite possibly be older version. >>> >>> This does also introduce the issue that maybe we should support http:// >>> and https:// in the connection address supported by the CLI. It would >>> make the addresses easier for end users to understand although it would >>> not be an option to access the HTTP interface directly. >>> >>> Regards, >>> Darran Lofthouse. >>> >>> >>> On 09/07/13 17:03, Jason Greene wrote: >>>> -1 to the CLI assuming a remoting connection. We are likely to turn off the remoting port in the default config before Final. >>>> >>>> A good solution would IMO be something like a combination of: >>>> >>>> 1. If no port is specified try http remoting on 9990, then fallback to 9999 printing a message >>>> 2. If 9999 is specified assume traditional remoting >>>> 3. All other ports assume http-remoting >>>> >>>> On Jul 9, 2013, at 10:22 AM, Darran Lofthouse <darran.lofthouse(a)jboss.com&gt; 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 >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> -- >>>> Jason T. Greene >>>> WildFly Lead / JBoss EAP Platform Architect >>>> JBoss, a division of Red Hat >>>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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.

This has its own backward compatibility problems, as now your scripts will break if you have upgraded you cluster to WF8.

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.

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

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

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

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

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