9:11 p.m.
[
https://issues.jboss.org/browse/WFCORE-1987?page=com.atlassian.jira.plugi...
]
Brian Stansberry commented on WFCORE-1987:
------------------------------------------
I would expect getDomainResults to return an undefined node for a write-attribute call.
The key thing is it's concerned with the *result* child of the response that goes to
the user, not the complete response. The result of a write-attribute is
'undefined':
{code}
{
"outcome" => "success",
"result" => undefined
}
{code}
Does the A2 node have the warnings you expect? If so you'll need to propagate those to
A1 by reading them from A2 and calling context.addWarning, similarly to how it currently
reads the result from A2 and passes it to A1 by calling context.getResult().set(...)
What needs thought is how to deal with warnings that come from slave HCs and from the
servers as part of domain rollout. My impression from your comments is that in the case of
servers, the 'server-results' structure is showing the warnings from the servers,
as part of each server's response. Correct? If so, that sounds ok.
For these domain rollout ops, I think it's fine to ignore warnings from the slave HCs.
They should be redundant, same as what the master generated in your A2 response.
All this is about ops that result in a domain-wide rollout (i.e. that go the
OperationCoordinatorStepHandler.executeTwoPhaseOperation path). This feature also needs to
deal with ops that go the executeDirect path or that are proxied steps in a composite that
goes the executeTwoPhaseOperation. That is
/host=slave:do-something-that-generates-a-warn
or
/host=slave/server=a:do-something-that-generates-a-warn
or
/host=master/server=a:do-something-that-generates-a-warn
Aha! It looks like that is largely handled. See ProxyStepHandler L199-201 -- any headers
from the proxied process are copied into the local response.
This will all need to be verified via tests.
Create request/response reporting mechanism
-------------------------------------------
Key: WFCORE-1987
URL: https://issues.jboss.org/browse/WFCORE-1987
Project: WildFly Core
Issue Type: Enhancement
Components: Remoting
Reporter: Radim Hatlapatka
Assignee: Bartosz Baranowski
Labels: downstream_dependency
In certain cases it is useful to send back, to client, some sort of context information
about the outcome of operation. For instance, when change in configuration warrants
another one and without it, after reload/restart server could not operate properly. For
instance JBEAP-7284.
Scope of this enhancement are:
a) way to send back information
b) control level of "information" - just like in case of loggers
a) Information will be sent in response headers, under "warnings" key. Each
entry, "warning" will contain operation, address, level/severity and i18n string
with proper ID.
b) default level threshold would be "WARNING", if user requires more detailed
information, he can request it via operation-headers->warninig-level
Example:
{noformat}
{
"outcome" => "success",
"response-headers" => {
"warnings" => [
{
"warning" => "WFLYCTL0436: Couldn't convert
'XXX' into proper warning level, threshold falling back to 'ALL'. Possible
values: SEVERE,WARNING,INFO,CONFIG,FINE,FINER,FINEST",
"level" => "ALL",
"operation" => {
"address" => [
("subsystem" => "undertow"),
("server" => "default-server"),
("http-listener" => "default")
],
"operation" => "write-attribute"
}
},
{
"warning" => "WFLYUT0090: Worker used in http-listener:
'puppet-master', must be used in remoting subsystem.",
"level" => "WARNING",
"operation" => {
"address" => [
("subsystem" => "undertow"),
("server" => "default-server"),
("http-listener" => "default")
],
"operation" => "write-attribute"
}
}
],
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
2880
days inactive
2880
days old
0 comments
1 participants
participants (1)
-
Brian Stansberry (JIRA)