[wildfly-dev] Automatically resolving expressions in the CLI

[Alexey Loubyansky]

On 06/27/2014 04:45 PM, Brian Stansberry wrote:
> On 6/27/14, 8:27 AM, Alexey Loubyansky wrote:
>> On 06/26/2014 05:31 PM, 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.
>>
>> Keep in mind that ls is an example. There are other commands that will
>> have to support this feature once it's implemented in one place. Another
>> example is read-attribute command. The ability to resolve expressions
>> elsewhere will be a natural expectation then.
>> So, it has to be thought of as a general features that can be applied to
>> various cli commands.
>>
>
> Good point. Joe, we'd need a clear understanding of all the commands
> that would be affected.

At this point, it's ls, read-attribute and commands handled by 
GenericTypeOperationHandler (which means [xa-]data-source, jms-topic, 
-queue, -connection-factory, etc).

The generic handler includes action read-resource (e.g. w/o other 
optional arguments 'data-source read-resource --name=ExampleDS'), which 
is basically a formatted result of :read-resource.

In general, it could be applied to any command displaying an attribute 
value to the user.

Alexey

>
>> IMO, the values returned should just be replaced with the resolved ones
>> for display. Some commands support --verbose argument, in which case
>> additional info is displayed in columns, there we could include the
>> original value.
>> The output of the cli commands in some cases is parsed by scripts or
>> other code, so keeping it simple will help there too.
>>
>>> 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.
>>
>> Current tab-completion supports dependencies of command arguments and
>> their values on the current context (connection to the controller,
>> standalone/domain mode, the presence of other arguments on the line and
>> the values specified for them, etc). Technically, there shouldn't be an
>> issue.
>
> Ok, good.
>
>> I am more concerned about how intuitive that will look like for the user
>> in various contexts.
>>
>
> Yes, I think the UX aspects are the more significant ones.
>
>> Alexey
>>
>>> 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>