[wildfly-dev] cli variables

[Brian Stansberry]

This all sounds like variations of the kinds of things we talked a bit 
about when we created the management-client-content branch of the 
management resource tree. Where we currently store rollout plans. That 
stuff doesn't get persisted to the xml config (because it isn't part of 
the server side configuration) but it does get stored in the content repo.

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


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat