]
Richard Achmatowicz updated WFCORE-4905:
----------------------------------------
Git Pull Request:
Provide common capability for Remoting connectors
-------------------------------------------------
Key: WFCORE-4905
URL:
https://issues.redhat.com/browse/WFCORE-4905
Project: WildFly Core
Issue Type: Bug
Components: Remoting
Affects Versions: 11.0.0.Final
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Priority: Major
Fix For: 11.0.1.Final
The EJB3 subsystem has an element <remote/> which performs a few different
functions relating to external clients accessing EJBs on the server:
* sets up a Remoting connector service so that external clients may connect to the server
using EJB / Remoting or EJB / HTTP Upgrade / Remoting
* sets up client mappings entries for those remote clients which are used in topology
updates to allow the client to find the server's connectors
The Remoting subsystem has two connector types which may be supplied to the <remote
connector-ref/> attribute. <connector name="remoting-connector"/>
represents a Remoting endpoint and <http-connector name="http-connector"/>
represents an Undertow listener which may be used with HTTP Upgrade.
At present, in the Remoting subsystem, these connectors have two separately defined
capabilities:
// for <connector/>
private static final String CONNECTOR_CAPABILITY_NAME
="org.wildfly.remoting.connector";
static final RuntimeCapability<Void> CONNECTOR_CAPABILITY =
RuntimeCapability.Builder.of(CONNECTOR_CAPABILITY_NAME, true).build();
// for <http-connector/>
private static final String HTTP_CONNECTOR_CAPABILITY_NAME =
"org.wildfly.remoting.http-connector";
static final RuntimeCapability<Void> HTTP_CONNECTOR_CAPABILITY =
RuntimeCapability.Builder.of(HTTP_CONNECTOR_CAPABILITY_NAME, true).build();
The proposal here is to allow referencing both connectors using a single capability base
name, "org.wildfly.remoting.connector" to simplify specification of the
capabilities which the <remote/> element needs (i.e. it may depend on one or the
other). These are both dynamically named capabilities, so their names will vary based on
the name of the management resource instance they represent. Because capability names are
considered public API, the existing capability name for
org.wildfly.remoting.http-connector cannot be removed to further simplify.