#### Feature capabilities

[[caps]]In the actual provisioned installation, the components that are represented as features in the configuration model may provide certain runtime capabilities that other components, also represented as features in the configuration model, may depend upon. There are two reasons why this *may* be important when resolving the configuration model for the installation to be provisioned:

. to make sure the configuration is consistent in a sense that the runtime requirements of its components are satisfied;

. to order the features in the configuration model for processing by the provisioning plugins based on their dependencies and runtime requirements.

Capabilities are represented as strings with a dot serving as a word separator. Here is an example of a feature spec providing a capability:
[source,xml]
----
 <feature-spec name="interface" xmlns="urn:jboss:galleon:feature-spec:1.0">
   <provides>
     <capability name="org.wildfly.network.interface"/>
   </provides>
   <params>
     <param name="name" feature-id="true"/>
     <param name="inet-address"/>
   </params>
 </feature-spec>
----

And here is a feature spec that requires the capability provided above
[source,xml]
----
 <feature-spec name="socket-binding" xmlns="urn:jboss:galleon:feature-spec:1.0">
   <requires>
     <capability name="org.wildfly.network.interface"/>
   </requires>
   <params>
     <param name="name" feature-id="true"/>
     <param name="port"/>
   </params>
 </feature-spec>
----

NOTE: In the examples above the capabilities were configured using constant values. This type of a capability is called a *static capability*. As a consequence, all the features of spec `interface` will provide the same capability `org.wildfly.network.interface`. And all the features of spec `socket-binding` will require the same capabality `org.wildfly.network.interface`.

##### Dynamic capabilities

It is also possible, however, to provide and/or require a capability that depends on the parameters of a specific feature. Dynamic capabilities are following the same dot-separated string format but include feature parameter names prefixed with `$` character. The examples above could be enhanced with dynamic capabilities as

[source,xml]
----
 <feature-spec name="interface" xmlns="urn:jboss:galleon:feature-spec:1.0">
   <provides>
     <capability name="org.wildfly.network.interface.$name"/>
   </provides>
   <params>
     <param name="name" feature-id="true"/>
     <param name="inet-address" nillable="true"/>
   </params>
 </feature-spec>
----

[source,xml]
----
 <feature-spec name="socket-binding" xmlns="urn:jboss:galleon:feature-spec:1.0">
   <requires>
     <capability name="org.wildfly.network.interface.$interface"/>
   </requires>
   <params>
     <param name="name" feature-id="true"/>
     <param name="interface"/>
     <param name="port" nillable="true"/>
   </params>
 </feature-spec>
----

Let's see how it will look like in an actual configuration

[source,xml]
----
 <feature-pack xmlns="urn:jboss:galleon:feature-pack:2.0"
                location="fp1@maven(org.jboss.universe:community-universe):1#1.0.0">
   <config name="main">
     <feature spec="interface">
       <param name="name" value="public"/>
     </feature>
     <feature spec="interface">
       <param name="name" value="secure"/>
     </feature>
     <feature spec="socket-binding">
       <param name="name" value="http"/>
       <param name="interface" value="public"/>
     </feature>
     <feature spec="socket-binding">
       <param name="name" value="https"/>
       <param name="interface" value="secure"/>
     </feature>
   </config>
 </feature-pack>
----

In the example above feature `interface:name=public` provides capability `org.wildfly.network.interface.public` which is required by feature `socket-binding:name=http`. And feature `interface:name=secure` provides capability `org.wildfly.network.interface.secure` which is required by feature `socket-binding:name=https`.

NOTE: More than one parameter could be used in a capability name. The parameters may appear in any part of the name, not necessarily at the end as in the example. The only rule is to use dot as a separator for the parameters and the static parts of the name.

###### Optional capabilities

In the example above, parameter `interface` in both feature specs is not nillable, which means the capability will always be provided by `interface` and always be required `socket-binding`. There could be cases though, when a parameter referenced from the capability name is nillable. In fact, if the parameter is null, the capability name will fail to resolve and provisioning will fail. However, dynamic capabilities can be marked as optional. Optional dynamic capability will be provided (or required) only if its name could be resolved (i.e. all the parameters referenced were not null). Here is the example illustrating optional capabilities in a feature spec:

[source,xml]
----
 <feature-spec name="specA" xmlns="urn:jboss:galleon:feature-spec:1.0">
   <provides>
     <capability name="$b" optional="true"/>
   </provides>
   <requires>
     <capability name="$c" optional="true"/>
   </requires>
   <params>
     <param name="id" feature-id="true"/>
     <param name="b" nillable="true"/>
     <param name="c" nillable="true"/>
   </params>
 </feature-spec>
----

