[jboss-jira] [JBoss JIRA] (WFCORE-1774) Use core-service=capability-registry to provide tab completion suggestions for model reference attributes

[Jean-Francois Denise (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291709#comment-13291709 ] 

Jean-Francois Denise commented on WFCORE-1774:
----------------------------------------------

[~brian.stansberry], I am wandering if looking at the last part of the name of a resource would allow to fully identify the capability. There is 2 * in the pattern, so the dynamic part of the capability should be composed of 2 items.
For example: org.wildly.clustering.transport.diagnostics-socket-binding ==> /subsystem=jgroups/stack=*/transport=*
We should propose: tcp.TCP, udp.UDP, ...

I have been looking at the  /core-service=capability-registry resource.capabilities list content. This list seems to contain all the registered capabilities. It seems that it contains enough information to complete capabilities. Am I right or does the resources tree contains more? 
A possible algorithm would be to:
1 Retrieve all capabilities from the registry
2 Expose all capabilities names that starts with the static part (retrieved in the capability-reference). static part being removed from the names exposed by completion.

For the diagnostics-socket-binding example, the registry contains:
org.wildfly.clustering.transport.diagnostics-socket-binding.tcp.TCP
org.wildfly.clustering.transport.diagnostics-socket-binding.udp.UDP
org.wildfly.clustering.transport.diagnostics-socket-binding.anothertcp.TCP

The completion would propose:
tcp.TCP
udp.UDP
anothertcp.TCP

I have a question related to static capabilities. Does it makes sense to have an argument to reference one? What would be the value for a static one?
Thanks.


> Use core-service=capability-registry to provide tab completion suggestions for model reference attributes
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1774
>                 URL: https://issues.jboss.org/browse/WFCORE-1774
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Jean-Francois Denise
>
> A "model reference" attribute is one whose value points to some other aspect of the model, e.g. "socket-binding" => "http". With the capability and requirement function we are rolling out in the server[1] we have the ability for clients to understand what values are valid for the reference. This should be used in CLI tab completion.
> [~claudio4j] has utitlized this for UI suggestions in HAL so he or Harald can be a resource for the  exact algorithm that has worked best. Here's the basics though:
> 1) This applies to attributes or operation params where the read-resource-description or read-operation-description includes a "capability-reference" field. The value of the field shows the static portion of the capability name. For example an attribute that's used for a socket binding name would show "org.wildfly.network.socket-binding".
> 2) The [/host=*]/core-service=capability resource shows information about what capabilities are available on the system. This includes 2 attributes "capabilities" and "possible-capabilities". The former shows the specific capabilities that are actually present; i.e. the resources that provide the capability are part of the configuration. The latter shows capabilities that could be present, given the installed extensions, if the relevant resources were added.
> That resource includes two operations "get-capability" and "get-provider-points" that can show more details about what resources provide a capability:
> {code}
> [standalone at embedded core-service=capability-registry] :get-provider-points(name=org.wildfly.network.socket-binding)
> {
>     "outcome" => "success",
>     "result" => ["/socket-binding-group=*/socket-binding=*"]
> }
> {code}
> That tells you that capabilities of type org.wildfly.network.socket-binding are registered by resources using address pattern /socket-binding-group=*/socket-binding=*
> 3) With that information the CLI can see what resources actually exist on the system and use the value portion of the final element of their address as the suggestion list for tab completion.
> HAL may be doing something slightly different from what I describe; they have concrete experience. 
> It may be possible for the API exposed by core-service=capability-registry to be enhanced to make this easier. If you want something, please don't hesitate to ask Tomaz Cerar or myself.
> [1] https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)