Bug 1032797

I was wrong reassigning this to Clustering. It's an enhancement request for the CLI tab completion function. The /subsystem=infinispan/cache-container=*/replicated-cache=* supports children of type "state-transfer" but children of that type do not allow any arbitrary child name. Rather, the valid names are declared in the /subsystem=infinispan/cache-container=ejb/replicated-cache=repl:read-resource-description(recursive=true) output.

{
    "outcome" => "success",
    "result" => {
        ...
        "children" => {
           ...
            "state-transfer" => {
                "description" => "The state transfer configuration for distribution and replicated caches.",
                "model-description" => {
                   "STATE_TRANSFER" => {
                       ...
                   }
                }
            }
        }
    }
}

If arbitrary child names were supported, the "model-description" node would have a child named "*".

To satisfy this enhancement request, tab completion would have to recognize that "*" was not present and that specific child names are present, and then use those specific child names for tab completion.

The problem here is caused by one of the steps along the address path not existing yet. Either the 'ejb' cache-container or the 'repl' replicated-cache is going to be created by this command, but is currently a non-existent entity.

The CLI uses ':read-child-names' to find possible values after an '=' in the address path, but that command fails because it requires all the nodes in the address to already exist.

If they do exist already, having been added by a previous command, the tab-complete works and fills in 'STATE-TRANSFER' successfully.

I'm not sure if that's a bug in the CLI tab-complete or in the ':read-child-names' operation. The ':read-child-types' operation can return successfully even with non-existent values in the address nodes, but I'm not sure if ':read-child-names' can, or should, be refactored to allow for that ability.

I don't think I want to change the behavior of :read-children-names. That can break people who assume the old behavior; i.e. that any value returned indicates an actual resource at that address.

The :read-resource-description output for the parent resource provides the needed data. I can see though why the tab completion isn't using that data, as it's quite a bit more verbose.

If we pursued this enhancement, the CLI might also need to change its behavior once the tab completion is done. That is, it should no longer provide further tab completion based on the existing assumption that the resource exists, since it does not. For example, if tab is hit after this:

/subsystem=infinispan/cache-container=ejb/replicated-cache=repl/state-transfer=STATE_TRANSFER:

the choice set should only include "add" and "read-resource-description" and perhaps some others. But "read-resource", "read-attribute", "write-attribute" etc would not be valid.

It's a can of worms and I'm not sure it's a good idea.

Closing this as per Brian's last comment.