Re: [wildfly-dev] Automatically resolving expressions in the CLI

Brian, Yes, the work so far searches the result that the existing 'ls' command receives for expressions and, if found, creates a ':resolve-expression(expression=___)' operation to resolve each one. On the domain side I can add an 'address' node to that command and target it towards a specific server. The existing ':resolve-expression(expression=___)' operation is already limited within the UX. Actually, I found out today, to a very strict extent. Which could be part of the user's confusion right now. The operation is currently unavailable anywhere deeper than the server level. Users are making requests to have expressions resolved in other commands and operations, which would certainly be convenient, but the tree level that they're giving as examples are all forbidden to the existing ':resolve-expression' operation. Which could be why they either don't know it exists, forget to use it, or even think it wouldn't work correctly.

For an example, they execute ':read-resource' at 'socket-binding-group=full-sockets/socket-binding=remoting', see an expression, but would have to 'cd ../../../..' to get access to the ':resolve-expression' operation. Since it's restricted so much I imagine most people don't even know it exists.

I'm not sure about the presentation. The user has to deliberate request the argument/param, so replacing the value might be fine, but having both would probably be nicer. Ståle, Thanks for the heads up. That option activator sounds like exactly what I want to do with the CLI side command arguments. I'll try to get a bit more familiar with æsh in the next few days. Joe ----- Original Message ----- > 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; http://aeshell.github.io/ 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 > if needed. > > 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 > approves :) > > here is the branch im working against atm: > > https://github.com/stalep/wildfly/tree/aesh_upgrade_take_two > > ståle > > On 26.06.14 10:31, Brian Stansberry wrote: >> 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 >> response? >> >> 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 >> careful examination. >> >> 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: ':read-resource' >>> >>> * 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 problem. >>> >>> Thanks, >>> >>> Joe Wertz >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >