[ https://issues.jboss.org/browse/WFCORE-1481?page=com.atlassian.jira.plugi... ] Tomas Hofman commented on WFCORE-1481: -------------------------------------- Status update I committed my current version here: https://github.com/TomasHofman/wildfly-core/commit/7f370a4a6ea1e8c48abc93... I. Storage.RUNTIME I think this case is working fine. The only issue is that even if one uses AbstractWriteAttributeHandler as writing OSH, the handler doesn't validates the operation correctly. That is because validation is performed in MODEL stage when the final value is not yet determined, so the validation passes even if it shouldn't. It could be solved by performing the validation in RUNTIME stage manually like: {code} .addReadWriteAttribute(LIST_ATTRIBUTE, readerOSH, new OperationStepHandler() { @Override public void execute(OperationContext context, ModelNode operation) throws OperationFailedException { context.addStep(operation, (context1, operation1) -> { // validate final ModelNode syntheticOp = new ModelNode(); syntheticOp.get(LIST_ATTRIBUTE.getName()).set(operation.get(VALUE)); LIST_ATTRIBUTE.validateOperation(syntheticOp); // set runtimeListAttributeValue = operation.get(VALUE); }, OperationContext.Stage.RUNTIME); } }) {code} So the person implementing the attribute has to be aware that: * he must add RUNTIME steps in his reader/writer OSHs, * he must perform validation manually, if he wants it. II. Storage.Configuration I still little bit struggle with composite operations, particularly in that test case which you were looking at. Lets have Storage.CONFIGURATION attribute with reader OSH like the one in the test case: {code} StringListAttributeDefinition LIST_ATTRIBUTE = new StringListAttributeDefinition.Builder("my-list-attribute") .setAllowNull(true) .build(); ResourceBuilder.Factory.create(...) .addReadWriteAttribute(LIST_ATTRIBUTE, new OperationStepHandler() { @Override public void execute(OperationContext context, ModelNode operation) throws OperationFailedException { context.getResult().set(runtimeListAttributeValue); } }, new AbstractWriteAttributeHandler(LIST_ATTRIBUTE) { @Override protected boolean applyUpdateToRuntime(OperationContext context, ModelNode operation, String attributeName, ModelNode resolvedValue, ModelNode currentValue, HandbackHolder handbackHolder) throws OperationFailedException { runtimeListAttributeValue = operation.get(VALUE); return false; } }); {code} and execute composite operation containing two list-adds: {code} { "operation" => "composite", "address" => [], "steps" => [ { "operation" => "list-add", "address" => [("subsystem" => "test")], "name" => "my-list-attribute", "value" => "value1" }, { "operation" => "list-add", "address" => [("subsystem" => "test")], "name" => "my-list-attribute", "value" => "value2" } ] } {code} Problem is that the second list-add reads before the first one writes. The step sequence would go: 1) begin operation M0 PrepareStepHandler 2) M0 executes M1 CompositeOperationHandler 3) M1 executes M2 ListAddHandler "value1" M3 ListAddHandler "value2" 4) M2 executes M4 ReadAttributeHandler M5 handler that modifies the value and adds write handler M3 ListAddHandler "value2" 5) M4 executes - which executes ReadOST, which in this case effectively reads from runtime M5 handler that modifies the value and adds write handler M3 ListAddHandler "value2" 6) M5 executes M6 WriteAttributeHandler - executes AbstractWriteAttributeHandler instance defined as WriteOST M3 ListAddHandler "value2" 7) M6 executes - resource model is updated M3 ListAddHandler "value2" R1 handler that updates runtime with \["value1"] 8) M3 ListAddHandler for "value2" executes, and is about to read from runtime again, but runtime still wasn't updated, so it reads \[] instead of \["value1"]. Then, after second ListAddHandler processes, we are left with: R1 handler that updates runtime with \["value1"] R2 handler that updates runtime with \["value2"] (instead of \["value1", "value2"]) I mean to me the test case seams like reader OST is reading from RUNTIME in stage MODEL, and writer OSH is writing to RUNTIME in stage RUNTIME, so they can never meet. I think the reader OST should either not be there, or should not read from a variable that is only updated in RUNTIME stage. -- This message was sent by Atlassian JIRA (v6.4.11#64026)