##### Feature capabilities

[[caps]]In the actual provisioned product, 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 two reasons why this *may* be important when resolving the configuration model for the installation to be provisioned:

. to make sure that 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 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 that expresses a requirement on 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 constants. This type of a capability is called a *static capability*. As a consequence, all the features of the *interface* spec will provide the same capability `org.wildfly.network.interface`. And all the features of the *socket-binding* spec will require the same capabality `org.wildfly.network.interface`.


###### Dynamic capabilities

It is also possible, however, to provide 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 parameters names prefixed with the `$` 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:1.0"
                groupId="org.jboss.pm.test" artifactId="fp1" version="1.0.0">
   <config>
     <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 the dot as a separator for the parameters and the static parts of the name.
