[jboss-jira] [JBoss JIRA] (WFLY-7987) Remove operations should warn the user if the resource has any dependents

[Guillermo González de Agüero (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-7987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13354562#comment-13354562 ] 

Guillermo González de Agüero commented on WFLY-7987:
----------------------------------------------------

I tried to remove the http socket binding and it in fact it doesn't allow me (as expected):

{code}
[standalone at localhost:9990 /] /socket-binding-group=standard-sockets/socket-binding=http:remove()
{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0367: Cannot remove capability 'org.wildfly.network.socket-binding.http' as it is required by other capabilities:
capability 'org.wildfly.undertow.listener.default' requires it for attribute 'socket-binding' at address '/subsystem=undertow/server=default-server/http-listener=default'",
    "rolled-back" => true
}
{code}

Manually editing standalone.xml and trying to boot fails with a "missing capability" error.

So it seems my original observations were wrong and that we are just facing a case when capabilities are not being used. I'll try WildFly nightly to see if it's already done on master. Thanks!

> Remove operations should warn the user if the resource has any dependents
> -------------------------------------------------------------------------
>
>                 Key: WFLY-7987
>                 URL: https://issues.jboss.org/browse/WFLY-7987
>             Project: WildFly
>          Issue Type: Task
>          Components: Web (Undertow)
>    Affects Versions: 10.1.0.Final
>            Reporter: Guillermo González de Agüero
>            Assignee: Stuart Douglas
>
> Services may have dependents that can't work if they are not present. Removal operations should prevent, or least warn the user then he is about to remove a service that may have side effects.
> Take a look at this example:
> {code:shell}
> [standalone at localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:add(header-name=X-test, header-value=test)
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/filter-ref=test:add()
> {"outcome" => "success"}
> [standalone at localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:remove()
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> [standalone at localhost:9990 /] :reload()
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> [standalone at localhost:9990 /] /core-service=management:read-boot-errors()
> {
>     "outcome" => "success",
>     "result" => [{
>         "failed-operation" => {
>             "operation" => "add",
>             "address" => [
>                 ("subsystem" => "undertow"),
>                 ("server" => "default-server"),
>                 ("host" => "default-host"),
>                 ("filter-ref" => "test")
>             ]
>         },
>         "failure-description" => "{\"WFLYCTL0412: Required services that are not installed:\" => [\"jboss.undertow.filter.test\"],\"WFLYCTL0180: Services with missing/unavailable dependencies\" => [\"jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]\"]}",
>         "services-missing-dependencies" => ["jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]"]
>     }]
> }
> {code}
> A new Undertow filter is created and assigned to a host. The filter is then removed, but the host still needs it.
> The problem is only seen after a server reload. The same thing happens when you remove, i.e. the default Servlet Container or the Bean pool of the EJB subsystem.
> My proposal is to at least add a response head to the remove operations listing affected (dependent) services. This would complement the new WildFly 11 capability registry.



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