]
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@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@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.