[jboss-jira] [JBoss JIRA] (WFCORE-4183) ReadResourceHandler returns runtime values stored in the DMR model even if include-runtime=false

Brian Stansberry (Jira) issues at jboss.org
Sat Oct 27 13:06:00 EDT 2018


Brian Stansberry created WFCORE-4183:
----------------------------------------

             Summary: ReadResourceHandler returns runtime values stored in the DMR model even if include-runtime=false
                 Key: WFCORE-4183
                 URL: https://issues.jboss.org/browse/WFCORE-4183
             Project: WildFly Core
          Issue Type: Bug
          Components: Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


The transaction subsystem has a read-write runtime-only attribute whose value it stores in the resource's DMR model node.  Its value is not persisted, so it really is runtime-only. (The value controls behavior of some runtime-only custom ops; this setup is basically a way of storing a semi-permanent param for those ops so it doesn't need to be passed with each invocation. Odd, but it is what it is.)

Problem is read-resource calls end up including the attribute when they should not:
 
{code}
[disconnected /] embed-server --admin-only=false
[standalone at embedded /] /subsystem=transactions/log-store=log-store:write-attribute(name=expose-all-logs,value=false)
{
    "outcome" => "success",
    "result" => undefined
}

[standalone at embedded /] /subsystem=transactions/log-store=log-store:read-resource(include-runtime=false)
{
    "outcome" => "success",
    "result" => {
        "expose-all-logs" => false,
        "type" => "default",
        "transactions" => undefined
    }
}
{code}

This happens because of ReadResourceHandler's behavior of trying to check for attributes in the DMR model that are not reflected in the ManagementResourceRegistration. Two possible fixes:

1) Make those checks a bit more sophisticated.

2) Remove that handling altogether as it's been *at least* five years since it was valid to have an attribute that is not reflected in the MRR.

I think I'll try #2.



--
This message was sent by Atlassian Jira
(v7.12.1#712002)


More information about the jboss-jira mailing list