[jboss-jira] [JBoss JIRA] (WFCORE-1987) Create request/response reporting mechanism

[Brian Stansberry (JIRA)]

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

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)