[wildfly-dev] Core and subsystem capabilities and requirements

Jeff Mesnil jmesnil at redhat.com
Thu Jul 3 07:09:58 EDT 2014


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).
In the second case, the subsystem may chose the provider of the capability based on the capability name (and both can be present).

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.

jeff


-- 
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/




More information about the wildfly-dev mailing list