On 23 Jun 2014, at 22:56, Brian Stansberry <brian.stansberry(a)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
See your question about uniqueness. Associating these with subsystems
provides a form of namespacing; without that we'd have to come up with
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
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
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.
JBoss, a division of Red Hat