[ https://issues.redhat.com/browse/WFLY-13839?page=com.atlassian.jira.plugi... ] Richard Achmatowicz edited comment on WFLY-13839 at 9/10/20 9:08 PM: --------------------------------------------------------------------- Some context. Undertow provides listeners such as ajp-listener, http-listener and https-listener which listen for incoming connections on ports (using a Listener instance which is registered with a Remoting-based ListenerRegistry). To represent this, all listeners register a dynamic capability org.wildfly.undertow.listener, where the rest of the capability name is filled out with the listener name. Additionally, the http-listener and https-listeners provide the ability to do HTTP Upgrade (using a named ChannelUpgradeHandler service) and this is represented by them registering a dynamic capability org.wildfly.undertow.listener.http-upgrade-registry, where the rest of the capability name is filled out with the listener name. The problem here was that the http-listener had an http-upgrade-registry capability registered,but not the https-listener. This was easily added to the HttpsListenerResourceDefinition. However, once this was done, the Undertow subsystem tests started failing with an unknown boot error. After some considerable debugging, this was traced to the use of a setCapabilityRequirement(String requirement) method on the ssl-context attribute of the HttpsListenerResourceDefinition. Adding in the second capability violated the "single-capability-only" requirement of this method and created an unknown boot error that was very difficult to trace. was (Author: rachmato): Some context. Undertow provides listeners such as ajp-listener, http-listener and https-listener which listen for incoming connections on ports (using a Listener instance which is registered with a Remoting-based ListenerRegistry). To represent this, all listeners register a dynamic capability org.wildfly.undertow.listener, where the rest of the capability name is filled out with the listener name. Additionally, the http-listener and https-listeners provide the ability to do HTTP Upgrade (using a named ChannelUpgradeHandler service) and this is represented by them registering a dynamic capability org.wildfly.undertow.listener.http-upgrade-registry, where the rest of the capability name is filled out with the listener name. The problem here was that the http-listener had an http-upgrade-registry capability registered,but not the https-listener. This was easily added to the ResourceDefinition. Once this was done, the Undertow subsystem tests started failing with an unknown boot error. Some time later, this was traced to the use of a setCapabilityRequirement(String requirement) method on the ssl-context attribute of the HttpsListenerResourceDefinition. Adding in the second capability violated the "single-capability-only" requirement of this method and created an unknown boot error that was very difficult to trace. -- This message was sent by Atlassian Jira (v7.13.8#713008)