Re: [wildfly-dev] cli variables

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