[wildfly-dev] Core and subsystem capabilities and requirements

As we continue with our work splitting the WildFly code base into a core repo and then separate repos related to sets of features that we need to solidify the contracts between the various features and between features and the core. I've taken a crack at an initial design document on this: see [1]. We also need to do the practical work of identifying the various dependencies between our existing subsystems, see [2] for a start on that. I'd love to get feedback on this thread regarding the proposed design, as well as get direct edits on the [2] doc to flesh out the existing relationships. Short version: A capability is a set of functionality that becomes available when a user triggers it by including some configuration resource or attribute in the management model. We'll identify capabilities via two strings: the name of the providing subsystem and then a capability name. A null subsystem name means a core capability; a null capability name means the base capability of the subsystem. Capabilities will also declare the identifiers of any other capabilities they require. There are two use cases for this capability/requirement data: provisioning (hopefully) and runtime. Hopefully this information can be used by provisioning tooling when building up a configuration document for the server/domain it is provisioning. So instead of always including a stock configuration for a subsystem, allow the user to tailor it a bit by declaring what capabilities are required. At runtime, when the configuration model is updated in such a way that a capability is now required, the OSH that handles that update will register the capability with the management layer in the MODEL stage. At the end of the MODEL stage the management layer will resolve all provided and required capabilities, failing the op if anything required is unavailable. Thereafter, in the RUNTIME stage an OSH that needs a capability from another subsystem or the core can request an object implementing the API for that capability from the OperationContext. I've thought a lot more about the runtime use case than I have about the provisioning use case. [1] https://community.jboss.org/docs/DOC-52712 [2] https://community.jboss.org/docs/DOC-52700 -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat