hi, this might be side stepping the topic a bit, but atm im working on
rewriting the cli to work with the latest version of æsh.
the new api in æsh have capabilities like specifying:
- an option activator (the option will not be shown during completion
until activator is "validated")
- option validator (will be processed after user have typed in a value)
- option completer
the homepage is here;
the docs are not quite
up to date, but they should give an idea of how it works.
the plan is to have designated completers for "browsing" the tree etc,
activators, validators etc. so the commands should be fairly simple
without much boilerplate.
with this change it would also be easy to add custom commands to the cli
ive just started and i cant dedicate 100% on this so i dont know when
ill be done, the plan is to target wildfly9. - if aleksey and brian
here is the branch im working against atm:
Thanks, Joe, for looking into this.
I'm curious what you've done so far with your 'ls --resolve-expressions'
work. Did you use the existing ':resolve-expression(expression=___)' low
level operation to process any expressions found in the :read-resource
There are a few aspects of this I'd like to explore.
One is the UX one. Is allowing 'resolve-expressions' in some contexts
and not others a good UX? Will users understand that? I'm ambivalent
about that, and am interested in others' opinions.
If it can work for a server and for anything under /host=*, then I'm
ambivalent. Any restriction at all is unintuitive, but once the user
learns that there is a restriction, that's a pretty understandable one.
If it only works for a patchwork of stuff under /host=* then I'm real
negative about it. An area of concern is /host=*/server-config=*, where
an expression might be irrelevant to the host, only resolving correctly
on the server that is created using that server-config. That will need
A second one is how this data would be displayed with 'ls'. A separate
additional column? Or replacing the current data? The answer to this
might impact how it would be implemented server side.
The third aspect is the technical issue of how to make any
'resolve-expressions' param or CLI argument available in certain
contexts and not in others. That's very likely solvable on the server
side; not sure how difficult it would be in the CLI high-level command.
FYI, for others reading this, offline Joe pointed out there's a related
JIRA for this: https://issues.jboss.org/browse/WFLY-1069
On 6/26/14, 5:41 AM, Edward Wertz wrote:
> I'm looking into whether it's possible to automatically resolve expressions
when executing operations and commands in the CLI.
>>From my understanding, there are two variations of the problem.
> * Operations are server-side processes that are accessed via ':' in the CLI
and, currently, the CLI presents the results returned as-is to the users. ex:
> * Commands are processes that get manipulated by the CLI before getting presented
to users. ex: 'ls'
> I've been experimenting with adding arguments to the CLI commands, like 'ls
--resolve-expressions', and gotten it working for the standalone and domain side of
things. However, I can't control the scope of the argument, so it's available in
situations that cannot accurately resolve expressions like the 'profile=full'
section of the domain tree. The results wouldn't be reliable.
> The same problem would apply to adding parameters to the server-side operations. The
scope of the operations themselves can be controlled, but not their parameters. An
execution like ':read-resource(recursive=true resolve-expressions=true)' can't
resolve expressions unless it's used against an actual server or host, but the
operation is available almost everywhere. Again, the results wouldn't be reliable.
> I'm wondering if anyone can suggest a way to attack this problem? There is
already a ':resolve-expression(expression=___)' operation, so users can somewhat
laboriously get the runtime values they want, but I can't figure out a way to
integrate the values into the existing framework successfully. Other than creating
entirely new operations and commands, like 'ls-resolve' and
':read-resource-resolve', which seems like an unsustainable way to solve the
> Joe Wertz
> wildfly-dev mailing list
Senior Principal Software Engineer
JBoss by Red Hat
wildfly-dev mailing list