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

[Bartosz Baranowski (JIRA)]

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

Bartosz Baranowski commented on WFCORE-1987:
--------------------------------------------

Simple test I've done with this was in "finishModelStage" of write attribute. For domain mode, if profile is active, I can see messages coming back, when attribute change. However when inactive profile is being edited nothing happens. When I alter server group profile, I get only response to that particular OP. 

WRT to include - it is kind of irrelevant, at least in this simple test. If parameter change, warning is sent in response, to check other parameters. If other profile has it set to proper value, no harm, if not, user knows what to do. This might not be the best way, but it is like that now. Might be something to improve on.

Im trying to figure out how inactive profile are being handled. Is it relevant to report on those?

> 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)