[wildfly-dev] cli variables

[Alexey Loubyansky]

That's an interesting idea. I'm gonna think about implementing it.

Then there could also be a (standard path) resource that could be read 
by the management tools to initialize the environment variables from its 
attributes.

On 12/04/2013 04:18 PM, ssilvert at redhat.com wrote:
> 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
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>