[jboss-jira] [JBoss JIRA] (WFCORE-1481) list-add operation doesn't work on login-modules attribute

[Tomas Hofman (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239962#comment-13239962 ] 

Tomas Hofman commented on WFCORE-1481:
--------------------------------------

Status update

I committed my current version here: https://github.com/TomasHofman/wildfly-core/commit/7f370a4a6ea1e8c48abc9330d7759afe5c4a0077#diff-caff84f283fb9500ec241e826f3a2728


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.

> list-add operation doesn't work on login-modules attribute
> ----------------------------------------------------------
>
>                 Key: WFCORE-1481
>                 URL: https://issues.jboss.org/browse/WFCORE-1481
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.1.0.Final
>            Reporter: Bartosz Spyrko-Śmietanko
>            Assignee: Tomas Hofman
>
> Executing list-add operation on login-modules results in the modules being replaced instead of appending new module.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)