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
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
>>> 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:
>>> 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.
>> wildfly-dev mailing list
wildfly-dev mailing list