Bug 976228

The CLI is only reflecting what happened in the domain management.

Upstream PR : https://github.com/kabir/wildfly/pull/28
PR : https://github.com/jbossas/jboss-eap/pull/1121

Upstream PR : https://github.com/wildfly/wildfly/pull/6091 
PR : https://github.com/jbossas/jboss-eap/pull/1121

I found a case, where the reload is still required:
[standalone@localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=FILE:read-attribute(name=append)
{
    "outcome" => "success",
    "result" => true
}
[standalone@localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=append, value=true)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
[standalone@localhost:9999 /] reload
[standalone@localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=append, value=true)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

Is this some kind of exception we can ignore?

The logging module uses its own logic with Propery to define the state instead of relying on the ReloadRequiredWriteAttributeHandler. As it is some 'generic' process for lgger configuration switches I don't know if we should change this.

@James
Can you please look into this? Is there anything that can be done in logging module regarding this issue, or shall I close it as verified leaving logging module as it is. 
Thanks.

Is the idea that if the value defined in the model is the same as the value being written that we just leave it? If that's the case then it should be fine and likely a simple fix.

In this particular case for append the default value is true. If the current value is UNDEFINED, e.g. the default, then it should still require a reload IMO.

@James -- the basic issue is to not trigger reload-required if the runtime value isn't actually going to change. See Emmanuel's ReloadRequiredWriteAttributeHandler fix which has some good code comments:

https://github.com/jbossas/jboss-eap/pull/1121/files

It's important to be careful about thinking about whether the value may have changed and to make a conservative decision (i.e. set reload-required if you aren't 100% certain the value is unchanged.) Emmanuel's code comment on that patch gets into that.

Fair enough. In this case I would be inclined to leave it as it is. This is one of the few attributes in the logging subsystem that actually requires a reload. Maybe it shouldn't even require it as it doesn't really do anything unless logging is being initialized anyway. What I mean is setting append to true doesn't mean anything at runtime as the stream is already open. That is the only reason I added the reload flag.

I'd also say it's probably rare when that flag would be changed anyway. It's probably set/changed once and left. So I say we leave it as is for now.

Based on the comments above, closing this as verified.

Verified on EAP 6.3.0.ER1