[jboss-jira] [JBoss JIRA] (WFCORE-4183) ReadResourceHandler returns runtime values stored in the DMR model even if include-runtime=false
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@embedded /]
/subsystem=transactions/log-store=log-store:write-attribute(name=expose-all-logs,value=false)
{
"outcome" => "success",
"result" => undefined
}
[standalone@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)