There is this issue to provide CLI preferences https://issues.jboss.org/browse/WFLY-1063. Here I'd like to address mainly this part "prod-db = /subsystem=jadada/database=jadada/ so you could call prod-db:read-resource" I'd like to get some opinion on the way it's gonna be implemented (and what I've done so far on a local branch). So, to address that I introduced variables. A variable starts with a $, e.g. $prod_db. (Using simply prod_db is not a good idea since it might conflict with actual parts of the paths, names, etc) Variables can be introduced with [disconnected /] set prod_db=/subsystem=datasources/data-source=ExampleDS Read with [standalone@localhost:9990 /] echo prod_db /subsystem=datasources/data-source=ExampleDS And unset with [standalone@localhost:9990 /] unset prod_db 'echo' without parameters will list all the variables and their values, 'set prod_db=' will have the same effect as 'unset prod_db', set/echo/unset will work with and w/o '$' prefix, tab-completion works everywhere. The variables may appear in: - operation request addresses, e.g. $prod_db/statistics=jdbc:read-resource; - operation names, e.g. $prod_db:$op(include-runtime=true); - operation parameter names and values, e.g. $prod_db:$op($param=$param_value); - the same for commands. Tab-completion helps complete the names as long as you type in '$' and then the rest of the line after the variable as usual. Variables added during the session are not persisted anywhere. But I've added .jbossclirc file. This file can be located in the current directory, wildfly home bin directory or specified with a system property. The content of the file is usual CLI commands and/or operations. So, the variables could be initialized there. This file, if located, will be executed before the CLI session (interactive or not) starts (but also after the system properties specified with --properties are set). As a side effect, '$' is now a special character and will have to be escaped. Otherwise the CLI might complain about an unresolved variable. So, this could potentially cause problems for existing scripts using $. Note, most of this replacement stuff can already be done with system properties using ${xxx} format (and btw scripts using '$' as in '${xxx}' won't be affected, of course). And for now I've made variable names follow the rules for Java identifiers. Any remarks, objections or suggestions? Thanks, Alexey _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

+1 on sharing them. On 03 Dec 2013, at 15:27, ssilvert(a)redhat.com <mailto:ssilvert@redhat.com> wrote: > You would store the variables and values in the management > model so that they could be shared by any user, script, or process. _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 12/4/2013 7:41 AM, Alexey Loubyansky wrote: > I haven't thought about that scope. But anyway, if it proves useful > it's doable. The use case I had in mind was for if I want to share a script that runs against servers or domain controllers on the network. As it is, I would have to tell the other person how to set all their variables. Giving the other person my .jbossclirc file is not a good idea because it also contains variable values that only pertain to my local environment.

It's the same concept as Maven's settings.xml file for local properties vs. the "shared" properties set in pom.xml. It might be that all you need is to simply allow a variable to refer to system properties on the server. That would be your shared variable. The $prod_db example you gave earlier would be a good candidate for a shared variable. So someone sets the property with: /system-property=prod_db/:add(value=mydatabase) Then anyone could use the $prod_db variable against that server no matter where the command runs from.

OTOH I think using server-side *system properties* to store client side values has a really bad smell.

A bit more below... On 12/4/13 8:26 AM, Alexey Loubyansky wrote: > On 12/04/2013 03:15 PM, ssilvert(a)redhat.com wrote: >> On 12/4/2013 7:41 AM, Alexey Loubyansky wrote: >>> I haven't thought about that scope. But anyway, if it proves useful >>> it's doable. >> The use case I had in mind was for if I want to share a script that runs >> against servers or domain controllers on the network. As it is, I would >> have to tell the other person how to set all their variables. Giving >> the other person my .jbossclirc file is not a good idea because it also >> contains variable values that only pertain to my local environment. > Variables can also be set in the beginning of a script. Although, I can > see advantages of keeping them out and simply relying on certain > variables in a script. > >> It's the same concept as Maven's settings.xml file for local properties >> vs. the "shared" properties set in pom.xml. >> >> It might be that all you need is to simply allow a variable to refer to >> system properties on the server. That would be your shared variable. >> >> The $prod_db example you gave earlier would be a good candidate for a >> shared variable. So someone sets the property with: >> /system-property=prod_db/:add(value=mydatabase) >> >> Then anyone could use the $prod_db variable against that server no >> matter where the command runs from. > That is indeed useful. BTW, don't we have aliases in the management > model that could also be used for this? > Management model aliases are static. They are used to provide backwards compatibility when we rename a resource or attribute. > Alexey > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >

Or how about a new command that sets a variable based on a read-attribute operation? I think this would satisfy the use case. [standalone@localhost:9990 /] set_from_read $prod_db=/some/path/:read-attribute(name=mydbvalue) On 12/4/2013 10:05 AM, ssilvert(a)redhat.com wrote: > On 12/4/2013 9:43 AM, Brian Stansberry wrote: >> OTOH I think using server-side *system properties* to store client side >> values has a really bad smell. > I agree it seems to smell but I can't figure out exactly why. The > alternative would be to create a second group of properties called > "client properties" or "cli properties". >> A bit more below... >> >> On 12/4/13 8:26 AM, Alexey Loubyansky wrote: >>> On 12/04/2013 03:15 PM, ssilvert(a)redhat.com wrote: >>>> On 12/4/2013 7:41 AM, Alexey Loubyansky wrote: >>>>> I haven't thought about that scope. But anyway, if it proves useful >>>>> it's doable. >>>> The use case I had in mind was for if I want to share a script that runs >>>> against servers or domain controllers on the network. As it is, I would >>>> have to tell the other person how to set all their variables. Giving >>>> the other person my .jbossclirc file is not a good idea because it also >>>> contains variable values that only pertain to my local environment. >>> Variables can also be set in the beginning of a script. Although, I can >>> see advantages of keeping them out and simply relying on certain >>> variables in a script. >>> >>>> It's the same concept as Maven's settings.xml file for local properties >>>> vs. the "shared" properties set in pom.xml. >>>> >>>> It might be that all you need is to simply allow a variable to refer to >>>> system properties on the server. That would be your shared variable. >>>> >>>> The $prod_db example you gave earlier would be a good candidate for a >>>> shared variable. So someone sets the property with: >>>> /system-property=prod_db/:add(value=mydatabase) >>>> >>>> Then anyone could use the $prod_db variable against that server no >>>> matter where the command runs from. >>> That is indeed useful. BTW, don't we have aliases in the management >>> model that could also be used for this? >>> >> Management model aliases are static. They are used to provide backwards >> compatibility when we rename a resource or attribute. >> >>> Alexey >>> _______________________________________________ >>> 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

On 12/04/2013 03:15 PM, ssilvert(a)redhat.com wrote: > On 12/4/2013 7:41 AM, Alexey Loubyansky wrote: >> I haven't thought about that scope. But anyway, if it proves useful >> it's doable. > The use case I had in mind was for if I want to share a script that runs > against servers or domain controllers on the network. As it is, I would > have to tell the other person how to set all their variables. Giving > the other person my .jbossclirc file is not a good idea because it also > contains variable values that only pertain to my local environment. Variables can also be set in the beginning of a script.

Although, I can see advantages of keeping them out and simply relying on certain variables in a script. > It's the same concept as Maven's settings.xml file for local properties > vs. the "shared" properties set in pom.xml. > > It might be that all you need is to simply allow a variable to refer to > system properties on the server. That would be your shared variable. > > The $prod_db example you gave earlier would be a good candidate for a > shared variable. So someone sets the property with: > /system-property=prod_db/:add(value=mydatabase) > > Then anyone could use the $prod_db variable against that server no > matter where the command runs from. That is indeed useful. BTW, don't we have aliases in the management model that could also be used for this? Alexey

The basics of this sound good. I'm not sure about the .jbossclirc part. How would this file differ from the jboss-cli.xml file? Emulating something like .bashrc could be really cool, but if doesn't end up being a pretty close analogue, it could be confusing. So what kind of things could be done with this file? 1) Simple association of variable names with simple strings. Makes sense, but could also be in the xml file. 2) Execution of commands? Connect commands could make sense; eliminate boilerplate from the CLI launch command. Other commands, I'm not sure what that could be. 3) Definition of functions; e.g. take what would be a separate CLI script with multiple commands, in-line it and name it. 4) Others? On 12/2/13 8:09 AM, Alexey Loubyansky wrote: > There is this issue to provide CLI preferences > https://issues.jboss.org/browse/WFLY-1063. Here I'd like to address > mainly this part > > "prod-db = /subsystem=jadada/database=jadada/ > so you could call prod-db:read-resource" > > I'd like to get some opinion on the way it's gonna be implemented (and > what I've done so far on a local branch). > > So, to address that I introduced variables. A variable starts with a $, > e.g. $prod_db. (Using simply prod_db is not a good idea since it might > conflict with actual parts of the paths, names, etc) > > Variables can be introduced with > > [disconnected /] set prod_db=/subsystem=datasources/data-source=ExampleDS > > Read with > > [standalone@localhost:9990 /] echo prod_db > /subsystem=datasources/data-source=ExampleDS > > And unset with > > [standalone@localhost:9990 /] unset prod_db > > 'echo' without parameters will list all the variables and their values, > 'set prod_db=' will have the same effect as 'unset prod_db', > set/echo/unset will work with and w/o '$' prefix, tab-completion works > everywhere. > > The variables may appear in: > > - operation request addresses, e.g. $prod_db/statistics=jdbc:read-resource; > - operation names, e.g. $prod_db:$op(include-runtime=true); > - operation parameter names and values, e.g. > $prod_db:$op($param=$param_value); > - the same for commands. > > Tab-completion helps complete the names as long as you type in '$' and > then the rest of the line after the variable as usual. > > Variables added during the session are not persisted anywhere. But I've > added .jbossclirc file. This file can be located in the current > directory, wildfly home bin directory or specified with a system > property. The content of the file is usual CLI commands and/or > operations. So, the variables could be initialized there. This file, if > located, will be executed before the CLI session (interactive or not) > starts (but also after the system properties specified with --properties > are set). > > As a side effect, '$' is now a special character and will have to be > escaped. Otherwise the CLI might complain about an unresolved variable. > So, this could potentially cause problems for existing scripts using $. > > Note, most of this replacement stuff can already be done with system > properties using ${xxx} format (and btw scripts using '$' as in '${xxx}' > won't be affected, of course). > > And for now I've made variable names follow the rules for Java identifiers. > > Any remarks, objections or suggestions? > > Thanks, > Alexey > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >