-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
If an attribute defines an OperationStepHandler the global read-attribute operation will execute the handler regardless if the resource exists.
Here's an example that will successfully execute and return the name invalid for the name attribute even though the resource does not exist.
/path=invalid:read-attribute(name=name)
(Note: example ^^^ no longer fails as the specific OSH for the read does the resource check.)
For attributes that use the default means of reading the attribute value the context.readResource(PathAddress.EMPTY_ADDRESS, false) is already invoked which will cause a failure. For attributes which define a custom read OSH the outcome is unpredictable as the existence of the resource is not validated before invoking the OSH.
The attached patch simply invokes the context.readResource(PathAddress.EMPTY_ADDRESS, false) before the invocation of the custom OSH.
- causes
-
JBEAP-8446 (7.1.z) Read attribute on IO subsystem worker's server succeeds even when it should fail
- Closed
- relates to
-
WFCORE-1796 read-attribute on non existing logger under /deployment throws NPE
- Resolved