[
https://issues.jboss.org/browse/WFLY-8551?page=com.atlassian.jira.plugin....
]
Brian Stansberry commented on WFLY-8551:
----------------------------------------
This is an interesting -- kind of ;) -- design question. What's
"mod_cluster" and what's "undertow"? I think the undertow adapter
is really part of undertow, so it needs a capability from mod_cluster. The adapter code is
in the mod_cluster source tree, which obscures this a bit, making the adapter seem more
like a part of mod_cluster than would be the case if the code were moved to the
"undertow" tree. (I'm not at all saying to move it.)
Also, the adapter implements some interfaces from mod_cluster, which isn't a clear fit
with capabilities. (I'm not at all saying that's wrong though.) Those interfaces
are kind of like a custom integration API that a capability can expose to dependents, but
the way they work is different. The required cap (mod_cluster) requires the dependent
(adapter) to do something (expose interfaces via ServiceLoader) vs the custom runtime API
approach where the required cap exposes something and the dependent looks that up and
invokes on it.
Establish proper capability contract for mod_cluster undertow
adapter
---------------------------------------------------------------------
Key: WFLY-8551
URL:
https://issues.jboss.org/browse/WFLY-8551
Project: WildFly
Issue Type: Bug
Components: mod_cluster
Affects Versions: 11.0.0.Alpha1
Reporter: Radoslav Husar
Assignee: Radoslav Husar
This was never exposed as there wasn't an expectation that somebody would depend on
this. Initial contract + workaround introduced by
https://github.com/wildfly/wildfly/pull/9897
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)