[wildfly-dev] cli variables

[ssilvert at redhat.com]

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 at localhost:9990 /] set_from_read $prod_db=/some/path/:read-attribute(name=mydbvalue)


On 12/4/2013 10:05 AM, ssilvert at 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 at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev