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

[Brian Stansberry (JIRA)]

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

Brian Stansberry commented on WFCORE-1481:
------------------------------------------

I looked at the test case and I don't think my word "contrived" was accurate; I think there was just a small mistake in the test in not reading the attribute value in Stage.RUNTIME. https://github.com/wildfly/wildfly-core/pull/1562 fixes that.

I think the fix you're trying will have problems with this scenario of working with a runtime-only attribute, but I think the existing code will too. I have some thoughts on how to get it to work, but it will be complex. If you can't find examples of runtime-only list and map attributes it may be ok to get the basic case corrected and file a JIRA for the runtime-only case. The runtime-only case fix will likely build on the simple case fix anyway. Probably by doing some gymnastics to get things to execute in Stage.RUNTIME at the right point. To get an effecdt like your Stage.DOMAIN suggestion, but Stage.RUNTIME instead of Stage.DOMAIN.

Quick summary of the trick:
1) Find out before doing any read-attribute whether the attribute is runtime-only. This is done via context.getResourceRegistration().getAttributeAccess(...).getStorageType().

2) If it's Storage.RUNTIME, then instead of registering the "another step that uses the data in the now-populated response node to do the rest of the manipulation" in Stage.MODEL, you do the following:

a) Register a step in Stage.RUNTIME that does nothing except
b) Registers also in Stage.RUNTIME "another step that uses the data in the now-populated response node to do the rest of the manipulation".

Here's how this works. I'll describe the manipulation of the list of steps below, with this id syntax M## or R## where M is Stage.MODEL, R is Stage.RUNTIME and ## is a sequence number.

I. The Storage.CONFIGURATION (i.e. non-runtime-only) attribute case looks like this:

1) Begin operation execution:

M0 (the PrepareStepHandler, which figures out which OSH is registered to handle the user's request and adds a step.)

2) M0 executes:

M0
M1 (ListAddHandler) 

3) M1 executes

M0
M1
M2 (the handler for read-attribute)
M3 (the handler that takes the M2 result and adds write-attribute)

4) M2 executes

(same queue as 3))

5) M3 executes

M0
M1
M2
M3
M4 (the write-attribute step)

6) M4 executes

M0
M1
M2
M3
M4 
R1 (a step to update the runtime to reflect the write-attribute)


II. The Storage.RUNTIME attribute case looks like this:

1) and 2) are the same as above.

3) M1 executes

M0
M1
M2 (the handler for read-attribute)
R1 (the odd R handler that just adds a step)

4) M2 executes

M0
M1
M2
R1 (the odd R handler that just adds a step)
R2 (added by M2 to do the read of the runtime in Stage.RUNTIME)

5) R1 executes

M0
M1
M2
R1
R2
R3 (the handler that takes the R2 result and adds write-attribute)

6) R2 executes

same as 5)

7) R3 executes

M0
M1
M2
R1
R2
R3
R4 (the write-attribute step, registered in Stage.RUNTIME)


8) R4 executes

M0
M1
M2
R1
R2
R3
R4 

So why the "odd" R1? Because R3 has to execute after R2, which means it needs to be registered after R2. The "odd" R1 executes after M2 so it is able to register R3 after R2.

The reality is things are even more complex than this. But this illustrates the kind of things that can be done to trigger execution in the right spot.

> 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)