Re: [wildfly-dev] cli variables

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 >