[wildfly-dev] Automatically resolving expressions in the CLI

Edward Wertz ewertz at redhat.com
Thu Jun 26 06:41:09 EDT 2014


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


More information about the wildfly-dev mailing list