4:52 p.m.
On 7/3/14, 6:09 AM, Jeff Mesnil wrote:
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
>> 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/CoreAndSubsystemCapabilityAndRequirement...
jeff
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat