[jboss-jira] [JBoss JIRA] (WFLY-9116) Eliminate use of RuntimeCapability.Builder add[Dynamic|Optional]Requirements, record missing requirements

[Brian Stansberry (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-9116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-9116:
-----------------------------------
    Summary: Eliminate use of RuntimeCapability.Builder add[Dynamic|Optional]Requirements, record missing requirements  (was: Eliminate use of RuntimeCapability.Builder addDynamicRequirements/addOptionalRequirements, record missing requirements)


> Eliminate use of RuntimeCapability.Builder add[Dynamic|Optional]Requirements, record missing requirements
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9116
>                 URL: https://issues.jboss.org/browse/WFLY-9116
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> RuntimeCapability.Builder addDynamicRequirements/addOptionalRequirements are deprecated because at the moment they have no practical function. The idea for them was to hold some metadata about a capability for description presentation in a ui or some kind of use by a provisioning tool. But that is a use case that hasn't been pursued.
> What they don't do is somehow automatically wire up requirements when the capability is registered, the way requirements added via RuntimeCapability.Builder.addRequirements are wired. That's because for a dynamic cap the dynamic part of the required cap's name is not known to the kernel, and for an optional requirement whether whatever condition makes the requirement non-optional has been met is unknown to the kernel.
> But it looks like there's some use of these methods where the code assumes some autowiring will happen. The problem reported in WFCORE-3040 is an example of this.
> Reproducer, starting with a near empty config a la standalone-minimalistic.xml:
> {code:java}
> /extension=org.wildfly.extension.undertow:add(module="org.wildfly.extension.undertow")
> /extension=org.wildfly.extension.io:add(module="org.wildfly.extension.io")
> batch
> /subsystem=undertow:add
> /subsystem=undertow/servlet-container=default:add
> /subsystem=undertow/server=default-server:add
> /subsystem=undertow/server=default-server/host=default-host:add(alias=["localhost"])
> /subsystem=undertow/server=default-server/http-listener=default:add(socket-binding="http")
> /subsystem=undertow/buffer-cache=default:add
> /subsystem=undertow/configuration=handler:add
> /subsystem=undertow/configuration=filter:add
> /subsystem=io:add
> /subsystem=io/buffer-pool=default:add
> /subsystem=io/worker=default:add
> /socket-binding-group=standard-sockets/socket-binding=http:add(port="\${jboss.http.port:8080}")
> run-batch
> {code}
> The server service is not added because the op is executed post-boot, so it's capability is tracked as requiring reload. But when adding the listener, the requirement for the server is not being added (because of this bug). So, without the requirement data to tell it things are not ready (see WFCORE-1106 for details) the kernel is not detecting the reload-required dependency and is trying to execute the stage RUNTIME steps for the listener add. These fail due to the missing dependency.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)