[jira] [Updated] (TAP5-2619) Flash persisted value cleared too early

["Raigo Aljand (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TAP5-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Raigo Aljand updated TAP5-2619:
-------------------------------
    Attachment: 0001-TAP5-2619-Flash-persisted-value-cleared-too-early.patch

> Flash persisted value cleared too early
> ---------------------------------------
>
>                 Key: TAP5-2619
>                 URL: https://issues.apache.org/jira/browse/TAP5-2619
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.4.5
>            Reporter: Raigo Aljand
>            Priority: Major
>         Attachments: 0001-TAP5-2619-Flash-persisted-value-cleared-too-early.patch
>
>
> *What happens*
> A page has two class fields. One is a flash persisted field (call it A) and the other is a session persisted field (call it B). In a single request i set field A and read field B. In the next request field A has a value of null (the value is gone).
> *What I expect to happen*
> In the next request field A should have the value it was set in the previous request.
> **I've done some research into the causes of this bug and a fix for it.
> *When did the bug appear*
> I'm certain enough that the bug appeared with the commit 435997738cee2cb9ea8b4b6ec3e5227dfdb2dc91. In it, restoring the state of persisted values became more lazy. If I revert the lazyness with restoring the persisted field state at page attach, the bug disappears.
> *What causes the bug*
> There is an operation the result of this is cached. This is called gatherChanges from persistentFieldManager. This is operation has the side-effect of nulling the session value of all flash persisted fields of the page.
> Previously this operation was called at the page attach stage. Now it is more lazy and is called when a persisted field is read.
> But not when it is set. In the buggy use case, the flash persisted field sets the session value, reading the other persisted field calls gatherChanges. The flash persisted field clears the field value that was just set. By the next request, the flash persisted value is gone.
> Previously it worked because gatherChanges was called at page attach stage. This is guaranteed to happen before any set of a flash persisted field.
> *How to fix*
> The fix is to call and cache gatherChanges at setting a persisted field in addition to getting it. Then the order of operation guarantees correct result.
> A patch with the fix and test for the bug will soon follow.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)