]
Bartosz Baranowski commented on WFCORE-1987:
--------------------------------------------
[~brian.stansberry] I think I figured out the reason for silent treatment of inactive
profile.
Just to clarify, I run existing domain.xml conf/xml, with some small change - Ive added
worker 'xxx'.
In in CLI
{noformat}
cd profile=default/subsystem=undertow/server=default-server/http-listener=default
:write-attribute(name=worker,value=xxx)
{noformat}
When operation hit controller primaryAnswer is set to value from step with
PrepareStepHandler: {"outcome" => undefined}. (A1)
This value is the same for next step, with DomainFinalResultHandler.
There is another value created in
(A2).
The A2 is actually one that is being edited in WriteAttributeHandler - this one contain
proper answer to operation.
When DomainFinalResultHandler kicks in, it gets both values:
- A1:
Im kind of trying to figure out what getDomainResults method is supposed to parse, but all
it return is "undefined" regardless of any content (outcome->success and
other nodes) in A2, and populate it into A1.
If profile is active, whole thing is saved by "serverResults" which is not empty
in this case and contain ~same result as A1.
Any thoughts?
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}