1:20 p.m.
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
2:52 p.m.
On 06/23/2014 01:20 PM, Brian Stansberry wrote:
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.
Here is what jumps out at me at first.
• I don't understand the reason to not allow optional dependencies on
capabilities. It would be of similar implementation complexity to the
suggested permutation implementation, however it would avoid the problem
of requiring 2ⁿ permutations for n optional dependencies.
• 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.
• I do think we should set up capabilities for things in the core model
(outside subsystems), especially as we seem to always increase the
number of things that can't be in subsystems (a trend I hope we can
reverse in the future).
• Can you define what having a capability be "provided by default"
means? Or perhaps more aptly, what it means to *not* be provided by
default?
• What about uniqueness? Can/should we enforce that each capability is
only ever satisfied by one subsystem?
--
- DML
3:31 p.m.
On Jun 23, 2014, at 2:52 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
On 06/23/2014 01:20 PM, Brian Stansberry wrote:
> 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.
Here is what jumps out at me at first.
• I don't understand the reason to not allow optional dependencies on
capabilities. It would be of similar implementation complexity to the
suggested permutation implementation, however it would avoid the problem
of requiring 2ⁿ permutations for n optional dependencies.
I had the same thought.
• 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.
I think Brian was trying to allow for thirdparty subsystems to potentially collaborate
without a global registration (like we have with Phases). In practice I would imagine all
of our out of the box subsystems would be using null. Alternatively we could just use some
kind of ad-hoc string as a group name or something.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
3:38 p.m.
On 23 Jun 2014, at 21:31, Jason Greene <jason.greene(a)redhat.com> wrote:
On Jun 23, 2014, at 2:52 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
> On 06/23/2014 01:20 PM, Brian Stansberry wrote:
>> 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.
>
> Here is what jumps out at me at first.
>
> • I don't understand the reason to not allow optional dependencies on
> capabilities. It would be of similar implementation complexity to the
> suggested permutation implementation, however it would avoid the problem
> of requiring 2ⁿ permutations for n optional dependencies.
I had the same thought.
I don’t really understand what you two are getting at here.
What would an optional requirement be? I can’t really get my head around “I would like
this to be there but I don’t care if it isn’t”.
>
> • 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.
I think Brian was trying to allow for thirdparty subsystems to potentially collaborate
without a global registration (like we have with Phases). In practice I would imagine all
of our out of the box subsystems would be using null. Alternatively we could just use some
kind of ad-hoc string as a group name or something.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:43 p.m.
On Jun 23, 2014, at 3:38 PM, Kabir Khan <kabir.khan(a)jboss.com> wrote:
On 23 Jun 2014, at 21:31, Jason Greene <jason.greene(a)redhat.com> wrote:
>
> On Jun 23, 2014, at 2:52 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
>
>> On 06/23/2014 01:20 PM, Brian Stansberry wrote:
>>> 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.
>>
>> Here is what jumps out at me at first.
>>
>> • I don't understand the reason to not allow optional dependencies on
>> capabilities. It would be of similar implementation complexity to the
>> suggested permutation implementation, however it would avoid the problem
>> of requiring 2ⁿ permutations for n optional dependencies.
>
> I had the same thought.
I don’t really understand what you two are getting at here. What would an optional
requirement be? I can’t really get my head around “I would like this to be there but I
don’t care if it isn’t”.
A good example is, Corba and JTS. Corba needs to be bootstrapped with a special
interceptor if JTS is enabled. Corba’s bootstrap could check some HAVE_JTS capability and
if present add the interceptor.
>
>>
>> • 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.
>
> I think Brian was trying to allow for thirdparty subsystems to potentially
collaborate without a global registration (like we have with Phases). In practice I would
imagine all of our out of the box subsystems would be using null. Alternatively we could
just use some kind of ad-hoc string as a group name or something.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
4:56 a.m.
On 23 Jun 2014, at 22:38, Kabir Khan <kabir.khan(a)jboss.com> wrote:
On 23 Jun 2014, at 21:31, Jason Greene <jason.greene(a)redhat.com> wrote:
>
> On Jun 23, 2014, at 2:52 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
>
>> On 06/23/2014 01:20 PM, Brian Stansberry wrote:
>>> 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.
>>
>> Here is what jumps out at me at first.
>>
>> • I don't understand the reason to not allow optional dependencies on
>> capabilities. It would be of similar implementation complexity to the
>> suggested permutation implementation, however it would avoid the problem
>> of requiring 2ⁿ permutations for n optional dependencies.
>
> I had the same thought.
I don’t really understand what you two are getting at here. What would an optional
requirement be? I can’t really get my head around “I would like this to be there but I
don’t care if it isn’t”.
I think we have such an use case in the messaging subsystem.
We will have a MESSAGING:CLUSTERED capability that will provide clustered messaging.
This capability may require JGROUPS:BASE capability to use the JGroups stack but it is not
mandatory since HornetQ also provides its own UDP stack that can be used if JGroups is not
there.
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
3:56 p.m.
On 6/23/14, 2:52 PM, David M. Lloyd wrote:
On 06/23/2014 01:20 PM, Brian Stansberry wrote:
> 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.
Here is what jumps out at me at first.
• I don't understand the reason to not allow optional dependencies on
capabilities. It would be of similar implementation complexity to the
suggested permutation implementation, however it would avoid the problem
of requiring 2ⁿ permutations for n optional dependencies.
I knew that would draw some comment and was already backing off it a bit
as I wrote various drafts. :)
The main thing is, say the user declares they want capability A, which
requires B and C. Then they say they want capability C. Did they forget
B or do they really not want it?
In the runtime case, there's no problem. The user is actually providing
a full configuration, and it's clear exactly what they need.
In the provisioning case, it's a bit less clear what they want. But it's
a valid requirement to say "you must declare B" if you want it.
• 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 do think we should set up capabilities for things in the core
model
(outside subsystems), especially as we seem to always increase the
number of things that can't be in subsystems (a trend I hope we can
reverse in the future).
Yes, I assume we will need to as well.
• Can you define what having a capability be "provided by
default"
means? Or perhaps more aptly, what it means to *not* be provided by
default?
I'm not sure which of these you're asking about, or maybe something
else. So I'll answer a couple things:
"default. boolean indicating whether a capability is provided by
default. Always true for a base capability (i.e. if a subsystem is
present, its base capability is as well.) Usage would be for the
provisioning use case described below, to reduce the amount of
information a user would need to provide to get a typical configuration.
TBD whether this make sense."
Say an infinispan subsystem provides a base capability that is local
caching only and also a clustered caching capability that requires
jgroups. 98% of the time a user who wants infinispan wants clustered
caching, so having it there by default saves a user who tells the
provisioning tool they want the extension also having to say they want
that capability. The 2% user who doesn't want that capability would need
to indicate that somehow in the spec they provide to the tool.
"Subsystems are only required to register a base capability if it either
depends on some other capability or exposes a runtime API. Otherwise, a
default base capability will be registered automatically at the end of
Stage.MODEL. (TBD: not certain is this default registration provides any
value.)"
Say a subsystem like jdr, which currently no one depends on. Does it
need to declare that it provides the "jdr" capability? Or can that just
be implicit?
This really depends on whether 1) there is any value in providing a
complete list of capabilities and 2) it's worthwhile not requiring a
subsystem to explictly declare a capability, but instead to just provide
a default one.
Re: 1) I was thinking about things like an installer/provisioning tool.
We don't want users thinking in terms of "I want these 4 capabilities,
and, oh, I also want these 3 subsystems too." Users should be able to
represent everything in terms of capabilities. So my answer to 1) is "yes".
Re: 2) if we decide capabilities are not bound to subsystems, then
there's no choice; a subsystem will have to declare a capability.
• What about uniqueness? Can/should we enforce that each capability
is
only ever satisfied by one subsystem?
In a given context (e.g. a server or a domain profile), yes.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
4:03 p.m.
On 6/23/14, 3:56 PM, Brian Stansberry wrote:
On 6/23/14, 2:52 PM, David M. Lloyd wrote:
>
> • I don't understand the reason to not allow optional dependencies on
> capabilities. It would be of similar implementation complexity to the
> suggested permutation implementation, however it would avoid the problem
> of requiring 2ⁿ permutations for n optional dependencies.
>
I knew that would draw some comment and was already backing off it a bit
as I wrote various drafts. :)
The main thing is, say the user declares they want capability A, which
requires B and C. Then they say they want capability C. Did they forget
B or do they really not want it?
Meant to say *optionally* requires B and C.
We may also would need to deal with cases where B *or* C but not both is
required. I think in that kind of situation though it would be better to
have two capabilities with non-optional requirements.
BTW, I thinking working out the EJB capabilities/requirements will be an
excellent way to start, as it has so many.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
6:09 a.m.
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).
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/
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
3825
days inactive
3839
days old
9 comments
5 participants
participants (5)
-
Brian Stansberry -
David M. Lloyd -
Jason Greene -
Jeff Mesnil -
Kabir Khan