[wildfly-dev] Core and subsystem capabilities and requirements

[Brian Stansberry]

On 7/3/14, 6:09 AM, Jeff Mesnil wrote:
>
> On 23 Jun 2014, at 22:56, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>
>> On 6/23/14, 2:52 PM, David M. Lloyd wrote:
>>> On 06/23/2014 01:20 PM, Brian Stansberry wrote
>>> • I don't understand the purpose of binding capability identifiers to
>>> subsystem identifiers.  It seems plausible to have a subsystem provide,
>>> for example, two capabilities now, but allow for a capability to be
>>> implemented separately in the future.  A concrete example would be the
>>> way we ultimately moved Servlet from JBoss Web to Undertow.  Ideally
>>> we'd only ever depend on the capability, making subsystems completely
>>> interchangeable.
>>>
>>
>> See your question about uniqueness. Associating these with subsystems
>> provides a form of namespacing; without that we'd have to come up with
>> something else.
>>
>> It's a valid point that we don't have to use association with subsystems
>> to provide this though. Any other suggestions?
>
> I’m not sure to understand the full scope of a capability.
> Is it planned to use capabilities to let different subsystems provides the same set of features?
>
> For example, if we had capabilities in AS7, would have both the web subsystem (with JBoss Web) and undertow subsystem provided the same capability for Servlets (e.g. HTTP:SERVLET) or two different (UNDERTOW:SERVLET and JBOSS-WEB:SERVLET).
>
> In the first case, a subsystem needing to use Servlets would not need to know which subsystems provides it (but we have to ensure only one subsystem providing the capability is present).

Ensuring that would be fairly simple by simply failing if the same 
capability is registered twice.

> In the second case, the subsystem may chose the provider of the capability based on the capability name (and both can be present).
>

That could be interesting, but I think it will likely prove to not be 
something we can consistently support. There will be various rules that 
would make having two implementations of the same capability in the same 
runtime impossible. For example, the default connection factory in JMS 
2.0, static registries that may be in different EE impls, etc.

It's an interesting question whether we want to try to support that kind 
of thing. If we did there would need to be some way for the core to 
distinguish cases where only one provider of a capability is allowed, 
and if more than one is allowed to decide which one is the "default" to 
provide to other capabilities that weren't specific about who provided 
the capability.

> I’m trying to figure out how I would name the messaging/JMS capability. At first glance, I am not sure I want to have the implementation (HORNETQ) be part of the capability name. I would prefer MESSAGING:JMS as it leaves open to change the JMS provider without affecting the capability to provide JMS.
>

I've updated that doc[1] to remove the requirement for including 
subsystem names in capability names, opting instead for simple 
namespacing by putting capabilities provided by the WildFly project 
under org.wildfly and mandating that other capability providers should 
use some rational namespace.

The other doc where I'm trying to document the existing relationships[2] 
still has the SUBYSTEM_NAME:XYZ syntax, but that's just because the goal 
is to write down what's currently there in easily understood terms, not 
so much to create the new names.

[1] 
https://community.jboss.org/wiki/CoreAndSubsystemCapabilitiesAndRequirements

[2] 
https://community.jboss.org/wiki/CoreAndSubsystemCapabilityAndRequirementListing

> jeff
>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat