[
https://issues.jboss.org/browse/WFCORE-750?page=com.atlassian.jira.plugin...
]
Brian Stansberry reopened WFCORE-750:
-------------------------------------
Reopening as I realize the existing work doesn't deal properly with includes.
An included profile or s-b-g needs to be treated as if it were a part of the including
profile/s-b-g's CapabilityContext. Otherwise a requirer in context
"profile-includer" will not be able to find capabilities in profile
"profile-included". And if a profile is mapped to a server-group along with
"s-b-g-includer", and requirers in that profile need sockets from
"s-b-g-includer" and "s-b-g-includee" that will be treated as an
incompatible mapping, since the fact "s-b-g-includer" includes
"s-b-g-includee" is not understood.
Capability requirement resolution for socket-bindings
-----------------------------------------------------
Key: WFCORE-750
URL:
https://issues.jboss.org/browse/WFCORE-750
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 2.0.0.Alpha5
In a managed domain the existing capability resolution mechanism will not work properly
for socket binding capabilities due to the relationship between socket-binding-groups and
profiles.
The same socket-binding capability name can be registered in different
socket-binding-groups. The existing approach can handle this easily enough by creating a
CapabilityContext for each group, a la what is down with profiles. But then the resolution
of requirements from resources in profiles needs to be handled.
The particular thing is that *all* requirements for socket bindings within a given
profile must be resolvable against at least one socket binding group. Otherwise, no server
group can map that profile and a socket binding group and end up with a combination that
will work on a server.
So, the capability requirement validation stuff will need a consistency check for this
case.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)