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(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:
> 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
Principal Software Engineer
JBoss by Red Hat