There can be a few reasons for that.
One is capabilities can require others without a reference attrribute in the model. (I
think such attributes what you meant by capability-reference.) Capabilities that are not
dynamically named (i.e. there’s only one of the type) are not referenced via attributes. A
number of things for example require org.wildfly.management.jmx.
Another is the introduction of capabilities in the code is incomplete, so things may still
use other services without having done the proper wiring via capabilities.
A third is only a capability can require a capability. That means if something needs a
capability it itself has to register a capability. We need to know who the dependents are
so we know what will happen if a depended-on capability is removed. But it’s possible no
other capability will require the dependent. It’s debatable but I think that’s ok. For
example org,wildly.jsr77 depends on org.wildfly.management.jmx but nothing depends on it.
But it seems useful to me to know that a server has capability org,wildly.jsr77 present.
On Jun 29, 2016, at 1:47 PM, Claudio Miranda
<claudio(a)claudius.com.br> wrote:
Also, FYI only these are used (have capability-reference)
org.wildfly.batch.job.repository
org.wildfly.batch.thread.pool
org.wildfly.clustering.singleton.policy
org.wildfly.data-source
org.wildfly.domain.profile
org.wildfly.domain.server-group
org.wildfly.domain.socket-binding-group
org.wildfly.io.buffer-pool
org.wildfly.io.worker
org.wildfly.network.interface
org.wildfly.network.outbound-socket-binding
org.wildfly.network.socket-binding
--
claudio(a)claudius.com.br
http://www.claudius.com.br
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat