[wildfly-dev] Proposing capabiities at completion time

Harald Pehl hpehl at redhat.com
Thu Sep 15 15:05:05 EDT 2016 

On Thu, Sep 15, 2016 at 2:21 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> I’m adding wildfly-dev in cc.
>
> Yes, the names of the parameters are ambiguous. And it’s not necessary for
> them to be ambiguous, as the “alternatives”, “required” and “requires"
> stuff lets us use clearly named params for different cases:
>
> “attribute” — required=true, alternatives=[parameter]
> “parameter - required=true, alternatives=[attribute], requires=[operation]
> “operation” - required=false
>
> An alternative is we could just drop all of those. The operation and
> attribute params are not necessary if the client has already done a
> read-resource-description or read-operation-description and already knows
> the value of the “capability-reference” descriptor. Then it could simply be
>
> /core-service=capability-registry:suggest-capabilities(
> address=[(subsystem=foo),(child=bar)],static-name=org.
> wildfly.network.socket-binding)
> {
>     “outcome” => “success”,
>     “result” => [
>         “http”,
>         “https”
>      ]
> }
>

>From the console's perspective that version would work best for us.

However I see one issue using this approach: If there are multiple
suggestions having the same name while referring to different resources.
This typically happens with attributes which have a capability reference to
"org.wildfly.network.socket-binding" (for instance attribute
"socket-binding" in "/subsystem=remoting/connector=*").

Using
/core-service=capability-registry:get-provider-points(name=org.wildfly.network.socket-binding)
returns "/socket-binding-group=*/socket-binding=*" which resolves to
several "http" socket-bindings in different socket-binding-groups.

Just using the names as suggestions would end up in several "http"
suggestions. What we do in that case in the console is to show some context:

standard-sockets / http
ha-sockets / http
full-sockets / http
...


>
> When thinking about this we should remember the dot/bracket syntax we
> allow for updating details of complex attributes via write-attribute:
>
> :write-attribute(name=complex.nested[2].field,value=http)
>
> For the CLI, just passing through “attribute”=>"complex.nested[2].field”
> is easier as there is no need for it to unpack the ‘.’ and ‘[]' syntax and
> find the description of ‘field’ and get the capabiity-reference.
>
> For the console, it may be easier to get the capability-reference and pass
> it instead. Easier than going from some code backing a gui widget and
> synthesizing "complex.nested[2].field” to pass to the server.
>
>
> > On Sep 15, 2016, at 6:40 AM, Jean-Francois Denise <jdenise at redhat.com>
> wrote:
> >
> > The operation argument is an optional argument that contains the
> resource operation name. In case the operation is present, the attribute
> argument means operation argument. Otherwise the attribute contains the
> name of an attribute. This is a draft of operation, the operation naming
> could be reviewed.
> > I don't think that this operation updates the capabilities registry,
> this is a readonly operation to retrieve capabilities.
> > JF
> >
> > On 15/09/16 12:41, Harald Pehl wrote:
> >> That looks very promising. Having such an operation would also cover
> the requirements of HAL. What's behind the "operation" parameter? Does it
> allow add / modify?
> >>
> >> On Thu, Sep 15, 2016 at 12:04 PM, Jean-Francois Denise <
> jdenise at redhat.com> wrote:
> >> Hi,
> >>
> >> I have spent some time looking at the semantic of the capability scopes
> (thanks to Brian help).
> >> A client "could" try to base its capability resolution by looking at
> capabilities present in the capabilities registry. Scope can be very
> complex, are possibly not fully modeled yet, and semantic could evolve in
> the future. So difficult for a client to rely on scopes to
> resolve the accessible capabilities.
> >>
> >> The server side has the logic to check the capabilities and could
> expose part of its engine logic to clients for capabilities resolution.
> Brian is proposing that the capabilities registry would expose a new
> operation:
> >> /core-service=capability-registry:suggest-capabilities(
> address=[(subsystem=foo),(child=bar)],operation=add,
> >> attribute=socket-binding)
> >> {
> >>     “outcome” => “success”,
> >>     “result” => [
> >>         “http”,
> >>         “https”
> >>      ]
> >> }
> >>
> >> It seems that the CLI "completion requirements" would be covered by
> this addition. I am wandering if it would also cover the HAL ones?
> >>
> >> Thanks.
> >>
> >> JF
> >>
> >>
> >> On 13/09/16 21:50, Harald Pehl wrote:
> >>> See my answers inline.
> >>> On Tue, Sep 13, 2016 at 12:04 PM, Jean-Francois Denise <
> jdenise at redhat.com> wrote:
> >>> Hi Claudio and Harald, thank you for your reply. Some questions
> in-lined. I am just discovering the capabilities topic ;-) On 12/09/16
> 19:47, Claudio Miranda wrote:
> >>> Your suggested approach looks similar to the way HAL does, however
> there are some differences. 1) There are many attributes that doesn't
> declare the capability-reference, (example: subsystem=transactions,
> attribute jdbc-store-datasource), then we emulate it.
> >>> How do you emulate this? You are hard coding the list of attributes
> that are reference to capabilities? You can point me to some code? Harald,
> what is the technical difficulty there? Are they real capabilities? If the
> referenced resource can't register capabilities, are they actual
> capabilities?
> >>> We have an internal registry [1] which is basically a map with the
> capability name as key and a class holding information about the capability
> as value [2]. Most entries in our registry are taken from
> /core-service=capability-registry, but to provide the capabilities also
> for WildFly < 11, we need to manually add entries to our registry during
> startup [3].
> >>>
> >>> 2) The capabilities and addresses are associated at bootstrap, this
> way HAL associates all capability-reference names to the target address it
> should lookup on at runtime. https://github.com/hal/core/blob/
> 26bb90653f60cfad2f3c3aac5964c4f125e18777/gui/src/main/java/
> org/jboss/as/console/client/meta/CoreCapabilitiesRegister.java
> >>> This is the information that the capabilities registry contains?
> Right? I should be able to retrieve all that from the registry?
> >>> Yes we read everything from /core-service=capability-registry
> >>> 3) For domain mode, the attributes that declares capabilities
> resources out of profile, as socket-bindings, there is a small
> inconvenient, we need to display the full resource address, as there is no
> way to associate the profile to the socket-binding, we need to show all
> socket-binding of all socket-binding-groups, see
> http://i.imgur.com/86VP1F9.png
> >>> The /<profile>/subsystem=transactions/process-id-socket-binding
> should be tagged with "capability-reference". Right? And it doesn't seem to
> be. Do you now the rational?
> >>> Right, the r-r-d result for  /<profile>/subsystem=transactions does
> not contain a "capabilities-reference" for the attribute
> "process-id-socket-binding". This seems to be a bug in the transactions
> subsystem. But actually it's a good example how we can still provide
> typeahead support for attributes which do not have a "capability-reference"
> info [4]. This does not involve the capabilities registry. It's just about
> adding typeahead support for attributes which reference some other
> resources, but do not yet have a "capabilities-reference"
> >>> Once the user has chosen a value, what are you setting as the value
> for the process-id-socket-binding attribute? Harald, you are saying that
> the resource name is taken as form input. So it means that only the last
> part of the resource address is stored? For example only "ajp"? Is it
> enough to fully identify the actual resource? Don't you need (full
> capabilities name + scope)?
> >>> Yes that's right, only the resource name is stored. Let's take the
> server-group resource as an example. It has the attribute "profile" which
> declares the "capability-reference" "org.wildfly.domain.profile". When
> adding the resource, only the profile name is stored. AIUI to identify /
> verify the profile the attribute value and the information from the
> capabilities-regisrty are used.
> >>>
> >>> Thank-you.
> >>> [1] https://github.com/hal/hal.next/blob/develop/meta/src/
> main/java/org/jboss/hal/meta/capabilitiy/Capabilities.java
> >>> [2] https://github.com/hal/hal.next/blob/develop/meta/src/
> main/java/org/jboss/hal/meta/capabilitiy/Capability.java
> >>> [3] https://github.com/hal/hal.next/blob/develop/app/src/
> main/java/org/jboss/hal/client/bootstrap/functions/
> ReadCapabilities.java#L65
> >>> [4] https://github.com/hal/hal.next/blob/develop/app/src/
> main/resources/org/jboss/hal/client/configuration/subsystem/transactions/
> TransactionView.mbui.xml#L47
> >>> --- Harald Pehl JBoss by Red Hat http://hpehl.info
> >> --
> >> --- Harald Pehl JBoss by Red Hat http://hpehl.info
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>
>


-- 
---
Harald Pehl
JBoss by Red Hat
http://hpehl.info
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160915/b68773de/attachment.html

More information about the wildfly-dev mailing list