]
Guillermo González de Agüero commented on WFLY-7987:
----------------------------------------------------
[~dlofthouse] Keep in mind that the filter and Servlet Container cases were just examples.
The same happens when removing the default mdb pool from the EJB subsystem: it works at
runtime, but complains after the reload.
I deduce from the format of the boot errors that they are already registered as
capabilities.
It is expected by design that a capability can't be remove while there are still any
services requiring it? Or is it up to the operation implementor?
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@localhost:9990 /]
/subsystem=undertow/configuration=filter/response-header=test:add(header-name=X-test,
header-value=test)
{"outcome" => "success"}
[standalone@localhost:9990 /]
/subsystem=undertow/server=default-server/host=default-host/filter-ref=test:add()
{"outcome" => "success"}
[standalone@localhost:9990 /]
/subsystem=undertow/configuration=filter/response-header=test:remove()
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 /] :reload()
{
"outcome" => "success",
"result" => undefined
}
[standalone@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.