[
https://issues.jboss.org/browse/WFLY-7987?page=com.atlassian.jira.plugin....
]
Brian Stansberry commented on WFLY-7987:
----------------------------------------
[~ggam] I think it's ok to keep this one for this issue. "Capabilities" is
just the internal mechanism for how we will detect and react to the issue you describe
here. If you prefer to open a different one that's ok, but this one seems good to me.
Thanks for asking about how fine grained to report issues. If it's easier for you to
do lots of small ones that's ok. But a good middle ground is to think of these as
referential integrity problems, where something in the configuration of subystem X refers
to something in the config of subsystem Y (or in the "kernel" where the kernel
means stuff that's in the config not in a subsystem, e.g. a socket-binding.)
If you see a problem between X and Y, then all other problems like that between X and Y
are likely related and could be fixed by the same general fix, which is to establish
proper capability contracts for X and Y and then wire up the system to use them. The hard
work in fixing that is thinking through the contracts and doing that right usually means
thinking through an entire subsystem, not just one thing detail. So if you find 3
different attributes between X and Y, they can all go in a general issue "Poor
referential integrity between X and Y". If X and Y are the same subsystem, then it
becomes "Poor referential integrity within X".
This one is "Poor referential integrity within the Undertow subsystem". From
your comment earlier it sounds like you found a problem with "Poor referential
integrity within the EJB subsystem."
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.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)