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

[Brian Stansberry (JIRA)]

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

Brian Stansberry commented on WFLY-7987:
----------------------------------------

Please use separate issues for different situations. The people involved in the fix may be different, and in cases like that lumping things together in a single issue can just lead to the issue not getting addressed.

The capability/requirement functionality is fairly new in WildFly and hasn't been rolled out across the code base, as you are seeing. But, it exists, and at this point it's correct to treat code that could use it and has negative behavior because it doesn't as having a bug. Having JIRAs helps raise the awareness of that. So, thanks for your reports! :)

> 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)